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METHOD AND SYSTEM RELATED 
TO AN AUDIO/VIDEO NETWORK 

BACKGROUND OF THE INVENTION 

5 Field of the Invention 

The present invention relates to the field of communication systems. 
More specifically, the present invention relates to equipment for home 
audio/video electronics. One embodiment of the present invention is a 
method and system downloading applications for controlling devices within 
10 a home audio/video network. 

Rem\tedAftt 

A typical home audiovisual equipment complement includes a 
number of components, e.g., a radio receiver, a CD player, a pair of 

1 5 speakers, a television, a VCR, a tape deck, etc. Components are connected 
to each other via sets of wires. One component is usually the central 
component of the home audiovisual system. This is usually the radio 
receiver, or the tuner/decoder. The control buttons and control switches are 
usually located on the front of the tuner and in many cases, some or all of 

20 these buttons and switches are duplicated on a hand held remote control 
unit. A user controls the home equipment by manipulating the buttons and 
switches on the front of the tuner, or alternatively, manipulating buttons on 
the hand held remote control unit. 

As consumer electronic devices have become more capable and 

25 more complex, demand for the latest and most capable devices has 

increased. As new devices emerge and become popular, new devices are 
purchased by consumers and "plugged" into their home audiovisual 
systems. The new device is simply plugged into the system. alongside the 
pre-existing, older devices (e.g., cassette tape deck, CD player, and the like). 

30 The new device is plugged into an open input on the back of the tuner, or 
some other device coupled to the tuner. The consumer 
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(e.g., the user) controls the new device via control switches on the new device itself, or via a 
separate remote control unit for the new device. 

As the number of new consumer electronics devices for the home audiovisual system has 
grown and as the sophistication and capabilities of these devices have increased, a number of 
5 problems with the conventional paradigm emerge. One such problem is incompatibility between 
devices in the home audiovisual system. In addition, where one device is much newer than 
another device additional incompatibilities may exist. For example, a new device might 
incorporate hardware (e.g., specific inputs and outputs) which enables more sophisticated remote 
control functions. This hardware may be unusable with older devices within the system. Another 
10 problem is the lack of functional support for differing devices within an audiovisual system. For 
example, even though a television may support advanced sound formats (e.g., surround sound, 
stereo, etc.), if an older less capable tuner does not support such functionality, the benefits of the 
advanced sound formats can be lost. Another problem is the proliferation of controls for the new 
and differing devices within the home audiovisual system. Each new device coupled to the 
15 audiovisual system often leads to another dedicated remote control unit for the user to keep 
track of and learn to operate. 

The conventional audiovisual system can also include a set-top-box. A set-top-box of the 
prior art is an intelligent receiver (decoder) that typically is used to supply an audio/video signal 
from a service provider to a television. The set-top-box generally performs a number of 
20 descrambling or decoding functions. It is possible to download very basic commands from the 
service provider that are executed within the set-top-box to provide very simple features or 
services to the consumer. Typical applications of this are a command set that enhances a video 
news clip displayed on a television with extra textual and/or graphics information that can be 
overlaid on the video news clip if requested. Also available is a home shopping service that 
25 allows a consumer to choose and purchase a service of goods by using a simple indicator. 
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However, these applications merely reside on and interact only with the television (or data entry 
device) directly coupled to the set-top-box and do not allow control of any other devices of the 
home audiovisual system. 
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g| I MMARY OF T HE INVENTION 

Accordingly, the present invention provides a system allowing improved interoperability 
within consumer audio/visual electronics products of a home system. The present invention 
further provides a system and method within a home audio/visual network that allows for 
5 expanded functionality for set-top-box applications. Specifically, the present invention offers a 
method and system for allowing devices of a home audio/video network to be controlled by one or 
more downloaded application programs originating from a service provider. 

A method and system-are described for downloading applications for controlling devices 
within a home audio/video network. Several consumer electronics products, e.g., television, VCR, 
10 tuner, set-top box (e.g., intelligent receiver/decoder, IRD), DVTRs, PCs. DVD (digital video disk) 
players, etc., can be coupled within the network to communicate together via a standard bus 
(e.g., IEEE 1394 serial communication bus). This allows devices of the network to control one 
another and obtain information regarding one another. In one embodiment, the communication 
architecture used is the home audio/visual initiative (HAVI) format The HAVI network offers 
15 unique advantages because the architecture offers for the home network many of the 

advantages of existing computer system networks. Namely, interconnected devices can share 
resources and provide open, well defined APIs that allow ease of development for third party 
developers. HAVI offers extended interoperability. 

In the home environment, one requirement for consumer electronics is ease of set-up.of 
20 devices by the consumers. This requires that a consumer can plug a device into the home 
network and have the home network and the device automatically configure themselves to 
ensure that the new device can be accessed and used. To ensure this, the present invention 
includes a home environment software architecture that allows any new device to be queried. 
Then a software abstraction of that device is created and made available to other elements in 
25 the network. Since it is likely that over the lifetime of the system, new devices will be added 
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whose capabilities and features are yet unknown, or only partially known to other devices, the 
present invention provides a mechanism that guarantees that all devices can be communicated 
with and controlled at some basic level. Thereafter, where possible, e.g., as more information is 
obtained about the device, a better abstraction of the new device is created by the present 
invention. 

A DCM or device control module is the software abstraction used by the present 
" invention to controFdevices within the home audio/video network. The DCM is a software 
abstraction of a device or service and provides an interface to that device. DCMs are hosted by 
intelligent nodes of the home audio/video network. Some devices, such as a set-top-box 
(intelligent receiver/decoder) or digital television act as both devices in the home network, 
communicating with other devices, and as gateways to external service providers (e.g., the 
internet, digital TV provider, cable provider, etc.) outside of the home. 

In the set-top-box of the present invention it is possible to download one or more 
application programs from a service provider that are run on the set-top-box. The application 
program generally is intended to provide some features or services to the home network. As a 
device on the home network of the present invention, the seMop-box has access to other devices 
in the home network. Therefore, the present invention allows the creation of downloadable 
applications that are transmitted from a service provider (e.g., a cable television provider, an 
internet web site, a telephone or other land line utility, a satellite broadcast service, etc.) to the 
consumer premises and instantiated on the set-top-box. In this case, the application programs 
can interact within the home network. 

Facilitating this functionality, the present invention provides a generic method of making 
available services and devices that are present in the network. The present invention registers 
the DCMs of the devices in the home network into a registry or name server. The home network 
of the present invention then provides a mechanism to allow any new downloaded application to 
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query this registry and receive back a communication end point for the DCM. The downloaded 
application is then provided with a mechanism to send requests to the DCM that are used to 
interact and control the actual devices of the home network. 
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BRIEF DESCRI PTION OF THF DRAWING S 

The present invention is illustrated by way of example and not by way of limitation, in 
the figures of the accompanying drawings and in which like reference numerals refer to similar 
elements and in which: 

Figure 1A shows a home AV network in accordance with one embodiment of the present 
invention. 

Figure 1B illustrates a logical bus configuration of the HAVI network of Figure 1A. 

Figure 2, shows an exemplary peer to peer, two IAV (intermediate audio vjdeo) node 
network in accordance with one embodiment of the present invention. 

Figure 3 shows a single FAV (full audio video) cluster HAVI network in accordance with 
one embodiment of the present invention. 

Figure 4 shows an FAV cluster integrated with an IAV peer to peer HAVI network. 

Figure 5 shows an exemplary HAVI network having multiple FAVs. 

Figure 6 shows a diagram of a set top box in accordance with one embodiment of the • 
present invention. 

Figure 7 shows a logical block diagram of one embodiment of the HAVI architecture of 
the present invention. 
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Figure 8 shows a layered logic diagram of one HAVI architecture in accordance with the 
present invention. 

5 Figure 9 shows a diagram of local and remote messaging in the HAVI architecture of one 

embodiment 

Figure 10 shows a diagram of a message being sent via 1394 in the HAVI architecture of 
one embodiment 

10 

Figure 11 shows a diagram of an application invoking another application in one 
embodiment of the HAVI architecture. . 

Figure 12A shows a first exemplary Ul display (e.g., on a television screen) for a device 
15 (e.g., the camcorder). 

Figure 12B shows a second exemplary Ul display (e.g., on a television screen) for a 
device(e.g., the camcorder). 



20 



Figure 13 shows a flow chart of a process for providing seamless interoperability and 
integration of a plurality of devices in a HAVI network by using the SDD information stored in 
each device in accordance with one embodiment of the present invention. 
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Figure 14 shows a flow chart of a process for providing a basic command functionality 
and an expanded command functionality between a plurality of devices in a HA VI network in 
accordance with one embodiment of the present invention. 

Figure 15 shows a flow chart of a process for ensuring future upgradability and 
expandability of devices in HAVI network in accordance with one embodiment of the present 
invention. 

Figure 16 shows a flow chart of a process for providing seamless interoperability and 
integration of legacy devices with the HAVI compliant devices in a HAVI network in accordance 
with one embodiment of the present invention. 

Figure 17A shows a flow chart of a process for controlling devices within a home 
audio/video network using an application program from an external service provider accordance 
with one embodiment of the present invention. 

Figure 17B shows a diagram of a HAVI network with the service provider in accordance 
with the process of Figure 1 7A. 
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nFTAIl ED DESCR IPTION OF THE INVENTION 

Reference will now be made in detail to the embodiments of the invention, examples of 
which are illustrated in the accompanying drawings. While the invention will be described in 
conjunction with the preferred embodiments, it will be understood that they are not intended to 
5 limit the invention to these embodiments. On the contrary, the invention is intended to cover 
alternatives, modifications and equivalents, which may be included within the spirit and scope of 
the invention as defined by the appended claims. Furthermore, in the following detailed description 
of the present invention, numerous specific details are set forth in order to provide a thorough 
understanding of the present invention. However, it will be obvious to one of ordinary skill in the 
10 art that the present invention may be practiced without these specific details. In other instances, 
well known methods, procedures, components, and circuits have not been described in detail as 
not to unnecessarily obscure aspects of the present invention. 

The present invention provides a home AV network which defines an open architecture 
15 for inter-operating CE devices in a home network. The interoperability aspects of the present 
invention define an architectural model that allows CE devices from any manufacturer to inter- 
operate and function seamlessly within the user's home AV system. The system of the present 
invention includes a combination of a base set of generic device controls with an method to 
extend a base control protocol as new features and new CE devices are deployed within the 
20 home AV network. In so doing, the architecture of the present invention is extensible, and can be 
readily modified and advanced as market requirements and technology change. The present 
invention and its benefits are further described below. 



NOTATION AND NOMENCLATURE 
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Some portions of the detailed descriptions which follow are presented in terms of 
procedures, steps, logic blocks, processing, and other symbolic representations of operations on 
data bits within a computer memory (see Figure 2). These descriptions and representations are 
the means used by those skilled in the data processing arts to most effectively convey the 
5 substance of their work to others skilled in the art. A procedure, computer executed step, logic 
block, process, etc., is here, and generally, conceived to be a self-consistent sequence of steps or 
instructions leading to a desired result. The steps are those requiring physical manipulations of 
physical quantities. Usually, though not necessarily, these quantities take the form of electrical 
or magnetic signals capable of being stored, transferred, combined, compared, and otherwise 
10 manipulated in a computer system. It has proven convenient at times, principally for reasons of 
common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, 
numbers, or the like. 

It should be borne in mind, however, that all of these and similar terms are to be 
15 associated with the appropriate physical quantities and are merely convenient labels applied to 
these quantities. Unless specifically stated otherwise as apparent from the following discussions, 
it is appreciated that throughout the present invention, discussions utilizing terms such as 
"processing" or "computing" or "translating" or "instantiating" or "determining" or "displaying" or 
"recognizing" or the like, refer to the action and processes of a computer system, or similar 
20 electronic computing device, that manipulates and transforms data represented as physical 
(electronic) quantities within the computer system's registers and memories into other data 
similarly represented as physical quantities within the computer system memories or registers or 
other such information storage, transmission or display devices. 
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ARPHITEHTURE OVERVIEW 

The Architecture of the present invention enables the creation of a Home AV system 
which provides for seamless support of new devices and problem free interoperability of devices 
in a home AV network. The most basic components of a system in accordance with the present 

5 invention are: a home AV interoperability architecture, a series of home AV interoperability 
interfaces, and a home AV network. The home AV interoperability architecture is a broad, over 

arching-term encompassing the physical network and the controlling programming interfaces. 

Interoperability interfaces is a-term used to describe the interactions and interfaces of the 
components of the AV architecture. In addition to providing a common command set, the 
10 interoperability interfaces provide a software architecture which allows new devices to be 
integrated into the network and provide their services in a seamless manner. The home AV 
network is the term used to describe the physical network and its topology. 

It should be noted that the home AV interoperability (HAVI) architecture of the present 
15 invention is an open, platform-independent, architecturally-neutral network that allows consumer 
electronics manufacturers and producers to provide inter-operable appliances. It can be 
implemented on different hardware/software platforms and does not include features that are 
unique to any one platform. The interoperability interfaces of the HAVI architecture are 
extensible and can be added to, modified and advanced as market requirements and technology 
20 change. They provide the infrastructure to control the routing and processing of isochronous and 
time-sensitive data (e.g., such as audio and video content). 

Specifically, the HAVI architecture provides: an execution environment supporting the 
visual representation and control of appliances; application and system services; and 
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communication mechanisms for extending the environment dynamically through plug and play or 
otherwise. 

It should be noted that the HAVI architecture supports legacy appliances (e.g., appliances 
5 that already exist and are available to users). This is important since the transition to more 
intelligent networked appliances is going to be slow. Most manufacturers will not suddenly begin 
producing only inteliigenf appliances and most consumers will not quickly begin replacing all of 
their existing appliances. 

10 in accordance with the present invention, there are two classes of legacy appliances. A 

first class includes "one-way" or unacknowledged control appliances. A second class includes 
controllable "two-way" appliances. Examples of one-way appliances are audio/video components 
controlled by infrared commands of a hand held remote. Two-way appliances provide 
confirmation of command execution, status and error reporting. Examples of two-way appliances 

15 include the recent introduction of well known IEEE 1394 enabled digital cameras. 

It should be noted that the home AV network (hereafter HAVi network) of the present 
invention provides support to accommodate future appliances and protocols through a write-once, 
run-everywhere common language. In accordance with the present invention, each appliance 
20 includes within it self-describing information concerning the user interface and the device control 
that can be used by an external controller. This information is specified as programs in the 
common language. 



25 



As described below, the underlying structure for such a network consists of set of 
interconnected clusters of appliances. Typically, there will be several clusters in the home, with 

SONY-50L2284 
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one per floor, or per room. Each cluster will work as a set of interconnected devices to provide a 
set of services to users. Often, one device will act as a controller for a set of other devices. 
However, the architecture is sufficiently flexible to also allow a home to consist of a single 
cluster with no master controller. 

5 

For example, in one embodiment of the present invention, an intelligent television in the 
family room of a user's home might function as the controller for a number of interconnected 
appliances. Each of the controlled appliances would have self describing data and possibly some 
associated control code. When these appliances are first connected, the controller obtains the 

10 user interface and the control program for the appliance. An icon representing the appliance may 
then appear on the television screen, and manipulating the icon may cause elements of the control 
program to actuate the represented appliance or appliances in prescribed ways. The exception 
to this model are legacy devices which Will have neither self describing data or Control code. For 
addition descriptions and related art regarding self describing data, the reader is referred to 

15 Ludtke, et al., A METHOD AND APPARATUS FOR INCLUDING SELF-DESCRIBING 

INFORMATION WITHIN DEVICES, provisional application number 60/054,327, filed on July 31, 
1997, which is incorporated herein by reference. 

It should be noted that the HAVI network of the present invention supports "Plug and. 
20 Play" consumer appliances are easy to install, and provide a significant portion of their value to 
the consumer without any action on the user's part, beyond physically connecting the cables. 
This is in distinction to existing appliances that require configuration to provide some major 
portion of their functionality. The goal is to offer 'hot 1 plug and play (not requiring the user to 
switch off appliances) where the connection method supports it safely and reliably. 
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In accordance with the present invention, an appliance configures itself, and integrates 
into a system-wide "look and feel" user interface, without user intervention. Low-level 
communication services provide notification when a new appliance is identified on the AV 
network. While there will often be settings the user may change to suit his or her preferences, the 
appliance does not require the user to do so in order to offer basic functionality. 

It should also be noted that the HAVI network of the present invention is flexible and 
supports multiple user interfaces, adapting to both the user's needs and the manufacturers.need 
for brand differentiation. In the AV network, protocols scale gracefully from very resource-rich, 
intelligent PC-like appliances to "dumb", resource starved appliances (e.g., a coffee maker or 
thermostat). To achieve this, the AV architecture allows low-end appliances to use the 
resources of more intelligent appliances in well-defined ways. In a similar manner, the AV 
architecture allows the specification of aggregate appliances where an abstract appliance is 
created from a logical collection of several lower-level appliances. 

And additionally, it should be noted that the HAVI network of the present invention 
supports existing standards. The HAVI network is complementary to several existing, well 
known, industry standards and technologies including: CEBus; Home Plug and Play; EHSI; 
VESA; Home Network, DAVIC, CoMMeND, Lonworks, USB, IEEE 1394, etc. Accordingly, one 
goal of the present invention is to provide an infrastructure into which existing devices can fit. 

THE SYSTEM M ODEL OF THE HAVI ARCHITECT! IRP 

With reference now to Figure 1A, a HAVI network 10a in accordance with one 
embodiment of the present invention is shown. As described above, the HAVI architecture 
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supports a wide range of devices including intelligent receiver/decoders (IRDs), tor example, the 
set top box 301, digital video tape records (DVTRs), video cassette recorders (VCRs), personal 
computers (PCs), digital video disk players (DVDs), etc., communicating via a common 
messaging system. Figure 1A illustrates the physical port-to-port connecting configuration 10a of 
5 an exemplary HAVI network. CE devices ("devices") 12-24 are shown connected together with 
bus segments 30a-30f. In one embodiment of HAVI, the IEEE 1394 serial communication bus 
standardjs used as^platfoim tp_p^ 

Figure 1B illustrates a logical bus configuration 10b of the HAVI network of Figure .1A. 

10 As shown in Figure IB. all of the devices 12-24 of the HAVI network can be viewed as logically 
coupled to a common IEEE 1394 serial communication bus 30. Within this bus configuration 10b. 
peer-to-peer device communication is supported. For example, as shown in Figure 1C, any device 
(having appropriate capabilities), e#, device 12. can send or receive communicatiori packets from 
any other device in the HAVI network. In the example of Figure 1B, the set-top-box (e.g., an IRQ) 

15 can receive messages from or generate messages to any of the other devices 14-24 of the HAVI 
network. 

Referring still to Figures 1A and 1B, as described above, the interoperability model in 
HAVI provides for the following: 1) support for existing devices; 2) a default control model; 3) a 
20 means to extend the default control model when new devices or functionality is brought to 
market; and 4) a common means for device representation (e.g., graphics user interfaces). To 
achieve the above, the HAVI architecture defines three types of nodes in the" home network: Full 
AV nodes (FAV), Intermediate AV nodes (IAV) and Base AV nodes (BAV). 
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A Full AV node is a device that contains a complete instance of the AV software model 
(described in detail below). This type of node generally has a richer set of resources and is 
capable of supporting a complex software environment. The primary distinguishing feature of a 
FAV is that it is able to take control responsibility for less sophisticated devices and does this by 
5 loading a control module, usually from the less sophisticated device, and executing it locally. 
Examples of such nodes would be Set Top Boxes (e.g., set top box 301), Smart TVs, general 
purpose home control devices, or even Home PC's. 

Intermediate AV.nodes are generally lower cost devices that have limited resources. 

10 They do not provide an execution environment for control modules and so can not act as master 
controllers within the home network. Because they have limited resources, they can access 
remote resources in one of two ways: by working with other IAV devices who provide some 
capability they lack, or by using an FAV node which supports a control module to control them. In 
this second mode of operation they rely on full AV nodes to provide such facilities as a display 

15 device, general purpose compute resources and some overall control framework. This allows Full 
AV devices to bind a variety of intermediate AV devices together to provide a service or 
abstraction to the user. 

Base nodes are nodes that are neither FAV or IAV nodes. These are two generic types: 
20 Legacy base nodes, and other base nodes. Legacy base nodes are devices that were built before 
the advent of the HAVI architecture. These devices often use proprietary protocols for their 
control, and quite frequently have a simple, well defined, control only protocol. Such devices can 
work in the HAVI network but require that a Full AV node act as a gateway. Communication 
between a Full or Intermediate AV node and legacy devices requires that the Home AV 
25 commands used in the HAVI architecture be translated to and from the legacy command 
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protocol. Other base nodes are devices that, for business or resource reasons, choose to 
implement future proof behavior using uploadable control software and do not carry any of the 
HAVI architecture or the message communication system. These devices will be controlled by an 
FAV node with a private command protocol between FAV and BAV node. 

5 

With the exception of legacy nodes, each node has, as a minimum, enough functionality to 
allow it to communicate with other nodes jnjhe system..„During.the-Course of interaction, nodes 
exchange control and data information to enable devices to inter-operate and will do so in a peer 
to peer fashion. This ensures that, at the communication level, no one device is required to act 
10 as a master or controller for the system. However, it also allows a logical master or controller 
to impose a control structure on the basic peer to peer communication model. Services in the 
HAVI network are provided by one or more nodes communicating amongst themselves to deliver 
a service to user or an application. Where it is necessary for a node to interact with* user, then 
the node negotiates with other nodes to access and use a display device. 

15 

Additionally, it should be appreciated that a distinction is made between Logical and 
Physical nodes. A good example of this distinction can be found in a normal TV set. Although the 
TV set is generally one physical box, it contains several functional components, e.g. the tuner, 
audio output etc. From the system point of view a physical node is an addressable peer node in 
20 the system. If the TV is constructed in such a way that its individual functional components are 
individually addressable, then it is logically one node and physically several nodes. Conversely, if 
it is constructed to have one addressable entity, then it is both a single logical node and a single 
physical node. 
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The IAV devices and FAV devices communicate by sending messages over the home 
network using a generic message passing system. When new devices join the home network, they 
are recognized and added to a global name database (registry). The registry holds information 
about their characteristics and provides a reference to a handler for that device. Other devices 
5 and services are able to query the registry to locate a device and then using the handler, can 
interact with the device. For additional descriptions and related art regarding the communication 
and identification processes of the present invention, the reader is referred to Ogino, et al., 
"METHOD AND SYSTEM FOR PROVIDING A DEVICE IDENTIFICATION MECHANISM 
WITHIN A CONSUMER AUDIO/VIDEO NETWORK", a US patent application filed on 6. Jan, 
10 1998, which is incorporated herein by reference. 

When a device is initially added to the home network, the system queries the device to 
ascertain its characteristics and capabilities. Once a device's characteristics are known, the 
architecture provides two methods of controlling it. The first method, level 1 interoperability uses 
15 a predefined message set. All IAV and FAV nodes can use this command set to access and 
control other devices (BAV nodes, because they are deployed before the architecture was 
defined, are controlled using legacy protocols). The provides a default level of control. The FAV 
nodes act as control nodes and create a local representation of the IAV node, known as a device 
control module (DCM) that provides an API used to send control commands to the device. 

20 

Level 2 interoperability within HAVI goes farther and supports future added functionality 
and new devices. To achieve this, a particular device can carry within its ROM, an override 
DCM that is uploaded from the IAV device, to the FAV device and replaces the default DCM for 
the particular device. This override DCM not only contains the basic level 1 command set for the 
25 particular device but also includes vendor specific commands to control advanced features of the 
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device. The model allows the device to inform another about its particular functionality. Since 
the override DCM may be loaded onto any vendor's FAV, the format of the DCM is 
architecture-neutral. 



5 To allow one device to discover the capabilities of another device and to determine which 

command set to use with that device, a standard device description structure is provided called 
the seifdesc^ingdat^SI^ data structure is extensible. It can be a 

small number of bytes describing the device type, e.g., TV, or VTR, etc. Alternatively, the SDD 
data structure can be a more complex structure also defining the override DCM and a graphical 

10 representation of the device. The graphical representation within the SDD data structure allows 
an FAV node to present a pictorial representation of the devices in the home network to users. 
By defining the graphical representation in a sufficiently generic manner, a device's SDD 
graphical data can be used in any vendor's product to display a user interface for that device. 
This provides an enhanced level of vendor interoperability and also allows a vendor to 

15 differentiate a product while maintaining within the general look and feel of the display device. 
This enables a control device (the FAV node) to present a general control user interface for all 
devices in the home network, irrespective of the differences in type and vendor. 

As described above, Legacy devices are devices that were buiit before the HAVI 
20 architecture or devices that select not to use HAVI. HAVI supports Legacy devices by providing 
Legacy DCMs to provide protocol conversions for Legacy devices. These Legacy DCMs can 
contain sufficient knowledge to allow them to support an existing 1 or 2 way'control protocol and 
provide a specific control interface to the devices that conform to HAVI. A legacy DCM acts as 
a bridge between the Legacy and HAVI devices. This approach allows HAVI also to interact 
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with any future device control protocols such as protocols being used for home energy 
management or security. 

It should be appreciated that the communications hardware and protocols used by the 
HAVI architecture are non-specific. The HAVI architecture is readily suited to the incorporation 
and use of any one of several communications mediums, with the simple requirement that the 
medium provides a generic communication mechanism f fhat ^upporfs'the HAVI interfaces. The 
basic model assumed is one of a logical communications back plane (e.g., IEEE 1394). All AV 
devices are assumed to be connected to this back plane, and can locate and communicatee all 
other AV devices, as shown in Figure 1B. In a physical setting, it is likely that this logical back 
plane will consist of more than one physical communication medium. It is further assumed that 
multiple protocols may be in use on different physical media. The Home AV architecture 
abstracts above all of this and presents a generic model of communicating nodes. It will provide a 
mechanism above the Transport layer (functionally like a socket) to ensure network 
transparency. This mechanism can be described as "reliable, ordered datagram service" which 
will provide all fragmentation and re-assembly. 

Accordingly, a goal of the present invention is to support each and every physical bus the 
same, such that an application need not care which physical transport it is using. However, with 
the familiarity of IEEE 1394 in the electronics industry, features of the present embodiment are 
illustrated and described in view of functioning with IEEE 1394. Other buses such as CEBus and 
USB may not require all the same features. 



Referring now to Figure 2, an exemplary peer to peer, two IAV node HAVI network 200 
dance with one embodiment of the present invention is shown. HAVI network 200 includes 
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a first IAV 201 (e.g., a television) coupled to a second IAV 202 (e.g., a receiver). IAV 201 and 
IAV 202 behave in a peer-peer manner, arbitrating for necessary resources amongst one another. 
They lack the resources to support the addition of a BAV or LAV device, but can perform 
meaningful activities within their context. The IAV is not required to provide any standard Ul 
5 capability. There is no provision in the AV Architecture for "forward compatibility" or discovery 
of new functions (e.g. IAV 201 only knows the functions that IAV 202 supports based on SDD 
provided upon connection of IAV2). However, in accordance with the present invention, the 
features of the SDD can be easily exploited to perform "ad-hoc" feature discovery. 

10 Figure 3 shows a single FAV cluster HAVI network 300 in accordance with one 

embodiment of the present invention. HAVI network 300 includes an FAV 301 (e.g., a set top 
box) respectively coupled to a first LAV 302 (e.g., a television) a second LAV 303 (e.g., a VCR) 
and a BAV 304 (e.g., a digital camera). In HAVI network 300, 

FAV 301 controls Legacy and Base AV devices (e.g., devices 302-304), providing cluster-wide 
15 services. 

Figure 4 shows an FAV cluster integrated with an IAV peer to peer HAVI network 400. 
In accordance with the present invention, the configuration of HAVI network 400 provides support 
for legacy devices 302 and 303 while enabling independent control to occur within the two IAV 
20 devices 401 and 402 when their resources are not in use by the FAV device 301 . The IAV 
devices 401 and 402 behave as peers to the FAV device 301. For efficiency, a resource conflict- 
policy can be implemented for both FAV to FAV or FAV to IAV resource requests. The IAV will 
be controlled by the FAV by via a DCM running in FAV 301. 
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Figure 5 shows an exemplary HAVI network 500 having multiple FAVs. HAVI network 
500 includes an additional FAV 501 (e.g., a satellite receiver). This configuration behaves in a 
similar manner to HAVI network 400 described above. In this configuration, the FAV devices 301 
and 501 act as peers. 

5 

THE COMPUTER SYSTEM PLATFORM 

With reference now to Figure 6, a diagram of a set top box 301 in accordance with one 
embodiment of the present invention is shown. As described above, any consumer electronics 
device can be a FAV and thereby provide a computer system platform for HAVI software. For 

10 instance, the set-top-box 301 device of the exemplary HAVI network contains special 
components that provide an operation platform for software components of the HAVI 
architecture which are described below. Specifically, aspects of the present invention, described 
below, are discussed in terms of steps executed on a computer system (e.g., processes shown in 
Figures 13 through 17A). Although a variety of different computer systems can be used with the 

15 present invention, an exemplary general purpose computer system is shown in the set-top-box of 
Figure 6. 

Set-top-box 301 of Figure 6, in addition to having a video/audio receiver (decoder) unit 
606 and MPEG unit 607 also includes an address/data bus 600 for communicating information, 

20 one or more central processors 601 coupled with the bus for processing information and 

instructions, a volatile memory 602 (e.g., random access memory RAM) coupled with the bus 600 
for storing information and instructions for the central processor 601 and a non-volatile memory 
603 (e.g., read only memory ROM) coupled with the bus 600 for storing static information and 
instructions for the processor 601. Set-top-box 301 can also optionally include a data storage 

25 device 604 ("disk subsystem") such as a magnetic or optical disk and disk drive coupled with the 
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bus 600 for storing information and instructions. Also included in the set-top-box 301 is a bus 
interface unit 608 for interfacing with the local bus 30 (e.g., an IEEE 1394 serial bus). Set-top-box 
301 can operate under a variety of different operating systems (e.g., Windows operating system, 
DOS operating system, Macintosh O/S), but in the present embodiment the Aperios operating 
5 system is used. 

THE HAVI SOFTWARE MODEL _ 

In accordance with the present invention, the computational units of the HAVI 
architecture (e.g., DCMs) are modeled as objects. Each object is a self contained entity, 
10 accessible through a well defined interface and executing within a well defined software execution 
environment. The software execution environment (e.g., set top box 301 from Figure 6) provides 
a set of well defined services (locally or remotely) that are also modeled as objects and can be 
accessed, using the communications infrastructure, via their well defined interfaces. 

15 Each object is uniquely named. No distinction is made between objects used to build 

system services and those used for application services. All objects make themselves known via 
the registry. Objects in the system can query the registry to find a particular service or device 
and can use the result of that query to send messages to that service or device. The identifier 
assigned to an object is created when the object registers. This identity, if required, is 

20 guaranteed to be persistent during the lifetime of the object and will remain persistent even in the 
face of a complete reboot of the home network. 

In accordance with the present invention, the objects communicate using a message 
passing model. An object that wishes to use the service of another object, does so by using a 
25 general purpose message passing mechanism that delivers the service request to the target 
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object The target object is specified using the unique object identifier discussed above. While in 
the present embodiment the message passing mechanism functions with IEEE 1394, it should be 
noted that there is no distinction between sending a message across a 1394 bus, or over a 
Control A1 link. In the same manner, there is no distinction between objects on the same node 
and one on a remote node. The actual implementation of the message passing infrastructure will 
depend on the system and networking environment and will differ from node to node and between 
verrdors.H4oweverrthe^actual1ormai of the messages must be common so that interoperability 
is assured. 

It should be appreciated that the general intent of the object model and messaging system 
is to provide a completely generic software model that is sufficiently flexible to allow multiple 
implementations' with a variety of software systems and languages. Details of the binding 
between messages and the code that handles them are left to the system implemented 

SOFTWARE ARCHITECTURE OVERVIEW 

The HA VI software architecture defines the way that the software model is used to 
support the HAVI architecture. In particular it defines the way that devices are abstracted and 
managed within the AV architecture. It defines the ways that interoperability is assured, and it 
defines the ways that future devices and services can be integrated into the architecture. 

Full AV nodes as software managers: In accordance with the present invention, Full AV 
nodes (FAVs) act as managers for Intermediate (lAVs) and Base (BAVs) nodes and provide a 
platform for the services that support the HAVI architecture. To achieve this they provide an 
execution environment which allow objects to control and communicate with services and devices. 
To ensure that devices are accessible within the Home AV network, the FAV nodes support a 
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software abstraction of the services that a device offers to others. As described above, this 
abstraction is referred to as a device control module (DCM). The DCM is modeled as an object 
within the software architecture but is refereed to hereinafter simply as the DCM to distinguish 
it. The interface that the DCM exposes to the rest of the system provides the means to access 
5 and control that device. In the general case, a FAV will manage a set of DCMs, one for each 
IAV node and base node in the home network or portion of the IAV network that it manages. 
Thus, it should be appreciated that from_an interoperability-perspective f the primary role of the 
FAV node is to manage DCMs of the present invention and act as an execution environment for 
DCMs. 

10 

Full AV node as controller and display device: In accordance with the present invention, 
in most cases, FAVs will have an associated display device which is used for display of AV 
content and of user interface (Ul) material. However, the HAVI software architecture does not 
mandate this and FAV nodes may be "headless". In this case they will cooperate-operate with 
15 other nodes to display content and Ul information (see below). However, FAV devices will be 
responsible for supporting the high level Ul APIs that provide the look and feel of the entire home 
network. The lower level graphic manipulation APIs will generally be located close to the graphics 
display device itself and are manipulated by the FAV high level APIs. 

20 Peer to peer architecture between full AV nodes: in a Home AV network in accordance 

with the present invention, there may be more than one FAV. In this case, each FAV cooperates 
with other FAVs to ensure that services are provides to the user. This allows FAV nodes to 
cooperate to share resources. For example, an FAV node that does not have direct access to a 
display device, may use a remote FAV node to display DCM user interfaces. Alternatively, a 
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FAV node may require the services of a data translation module that exists on a remote node to 
allow it to set up a data route between two AV devices. 



LEVEL 1 AND LEVEL 2 INTEROPERABILITY GENERALLY 
5 In accordance with the present invention, one of the major goals of the HAVI architecture 

of the present invention is to support interoperability between devices. This includes existing 
devices and future devices. To achieve that interoperability, the HAVI architecture of the 
present invention supports a general model that allows two levels of interoperability. These 
levels are referred to as Level 1 and Level 2. 

10 

Level 1 interoperability: Level 1 interoperability of the present invention addresses the 
general need to allow existing devices to communicate. To achieve this, level 1 interoperability of 
the present invention defines and uses a generic set of control messages (commands) that enable 
one device to talk to another device and a set of event messages that it should reasonably 
15 expect from the device. To support this approach a basic set of processes are required. These 
processes include device discovery, communication, and a generic message set. 

The device discovery process of the present invention provides for the fact that each 
device in the Home AV network needs a well defined method that allows it to advertise to others 

20 its characteristics. The approach we have adopted is to specify a data structure, required on all 
FAV and IAV devices, that contains information about the device and which can be accessed by 
all other devices. This data structure is referred to as a Self Describing Data structure (SDD). 
The SDD contains, as a minimum, enough information to allow another device to discover its 
basic capabilities and so infer the basic set of command messages that can be sent to that 

25 device and events it should reasonably expect to receive from that device. 
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The communication process of the present invention provides for the fact that once a 
device has determined the capabilities of another device, it then needs to be able to access those 
capabilities. To achieve that requires a general communication facility that allows one device to 
5 send a message containing a command request to another device. The general message service 
processes of the present invention were discussed above. 

Generic message set refers to the process required to support level 1 interoperability. 
This includes a well-defined set of messages that must be supported by all devices of a particular 
10 class. This ensures that a device can work with other devices, irrespective of the manufacturer, 
because all devices agree to a common set of generic commands. As discussed above, within the 
HAVI software architecture of the present invention, these commands are presented as a DCM 
to the rest of the system. 

15 These three basic processes of the present invention support at least a minimal level of 

interoperability. Sinc6, in most cases, any device can query the capabilities of another via the 
SDD, any device can determine the command set supported by another device. And since each 
- device has access to a generic messaging system, then any device can interact with any other 
device. 

20 

However, it should be appreciated that level 1 compatibility in accordance with the 
present invention only ensures that devices can inter-operate at a minimal or degraded level of 
functionality. The generic message set for each device class is a minimal and common set of 
commands. The SDD facility offers a means to provide some degree of customization of a 
25 device by providing information about its Ul and some aspects of its interaction model. Other 
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IAV devices can use this information to present an interface to the device. Alternatively, any 
FAV device can use this information to customize the generic DCM it has created for the device. 
However, it should be noted that a more extensible mechanism is also needed to allow a device to 
communicate to other devices any additional functionality it posses. Level 2 interoperability of 
the present invention provides this mechanism. Level 1 and Level 2 interoperability are discussed 
in greater detail below. 



LEVEL 1 AND LEVEL 2 DCMs 

As described above, the DCM of the present invention functions by providing access, 
control and interaction with a device. DCMs are typically instantiated (e.g., executed) on the 
resources of FAVs in the Home AV architecture. The DCM of the present invention provides an 
interface to a device and manages a Ul that the device wishes to present to users. 

In accordance with the present invention, with the level 1 interoperability, the DCMs 
created for devices are generic. They support a minimal command set that allows generic 
control of the device. "To support device specific features requires that the DCM provide access 
to such device specific features and is capable of presenting device specific features to users via 
the Ul. 

To achieve this, Level two interoperability is used. In accordance with the present 
invention, the Home AV architecture allows a device to provide an "override" DCM for the 
generic DCM that would normally be created for that device. The override DCM (e.g., level 2 
DCM) is capable of replacing the default DCM (e.g., level 1 DCM) on the FAV. It should be 
appreciated that the level 2 DCM could be retrieved from a variety of sources. One such source 
is the SDD of the device itself. In this case, the level DCM is fetched, received, or otherwise 
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acquired from the SDD of the device and instantiated in an FAV node when the device is installed 
into the system. Because the Home AV architecture is vendor neutral, it is necessary that the 
level 2 DCM work on a variety of FAV nodes, each with potentially different hardware 
architectures. To achieve this, the format of both the level 1 and level 2 DCMs of the present 
5 invention are architecture neutral such that a wide variety of software execution environments 
of the FAV nodes are able to instantiate and run the level 1 and level 2 DCMs. 

It should be appreciated that, in accordance with the present invention, once created and 
running within a FAV node, the DCMs of the present invention communicate with the IAV and 
10 BAV nodes in the same manner as described above using the basic messaging mechanism. 

As described above, there are many permutations of FAV, IAV and BAV nodes possible 
within a given HAVI network. These permutations generally fall into two types: HAVI network 
configurations that support an FAV device, and those that do not. This distinction essentially 
15 defines whether a HAVI network will be using a peer to peer configuration (e.g., as shown in 
Figure 2, where no FAV is present) or will be imposing some form of control hierarchy (e.g., the 
FAV cluster as shown in Figure 3). 

In accordance with one embodiment of the present invention, in the cases where no FAV 
20 is present, only level 1 interoperability is available and the devices are forced to use SDD 

information to discover other IAV capabilities, present those capabilities, and control the device.. 
In the cases where FAVs are present, DCMs are instantiated and uses. If these are level 1 (e.g., 
generic) DCMs, the devices are operating at level 1 interoperablity. If there is at least one level 2 
DCM present, then some of the devices are operating at level 2 interoperability. 
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In accordance with the present invention, it should be noted that a mixed mode of 
operation is possible in which clusters of devices are inter-operating under control of an FAV 
node, while other devices are inter-operating in a peer to peer fashion. In this manner, the 
flexibility of the present invention allows vendors the freedom to design and build devices ate all 
points on the cost/capability spectrum with the certainty that these devices will inter-operate 
"seamlessly with other devices in the HAVI network. 

Referring now to Figure 7, a logical block diagram 700 of one embodiment of the HAVI 
architecture is shown. Figure 7 shows an overall HAVI architecture in accordance with the 
present invention. The components shown in diagram 700 are as follows: 

Device manager 761 : Device manager 761 is responsible for creating and managing the 
DCMs that represent devices managed by an FAV device. 

Device Modules 720: These are the DCMs for individual devices. As described above, 
each DCM functions as a control point for a device and provides a Ul component and a control 
component. The DCMs (e.g., device modules 720) provide an API to allow other applications to 
access and manipulate the devices. 

Service Modules 730: These modules can be viewed as software devices They are 
DCMs for any software component (as opposed to a hardware device) that provides a general 
service to other devices or components in the home network. 

Comms Media Manager 740: This component is responsible for managing the underlying 
physical communications process. It provides an API that allows code modules to interact with 
the features of the communications media (e.g., IEEE 1394). 
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Registry 706: This is a seivice database. All DCMs tor physical devices and software 
services will register themselves in the registry 706 and all modules (e.g., device modules 720) can 
query the registry to get a handle for another device or module. 

Communications manager 750: This component is a low level abstraction of the 

5 communications media. 

Messaging 702: This component provides a basic message passing facility to allow both 
devices (hardware) and device modules 720 and service modules 730 to communicate with each 
other. 

Event Manage 703: This module provides a generic event service. This is a one-to-many 
10 communication service allowing notification in the HAVI network. 

Initialization manager 701 : This component is used as part of the device bootstrap 

process. 

Data routing 762: The data routing components is responsible for helping services set 
up routes between devices and devices modules. It takes into consideration the 'cost of 
15 transferring data via a particular route, the requirements on data format translation etc. This 
component is not needed for the basic architecture. 

AV Actions/Macros 763: this component is a manager for higher level AV actions which 
are groups of individual low level commands, i.e. it provides a macro service. This component is 
not needed for the basic architecture. 
20 High level Ul library 704: This component provides a set of high level Ul components that 

are used by device modules 720 to build Uls for their corresponding devices. This component is - 
not needed for the basic architecture. 

Application (and User) interface 705: This component provides the linkage between a 
common consumer electronics platform (CCEP) APIs of the HAVI compliant devices and 
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applications which are local or possibly remote. This component is not needed for the basic 
architecture. 

It should be appreciated that the above components as diagrammed in Figure 7 are 
5 abstractions of functionality, They are designed to make clear what functionality is included in 
the architecture for HAVI compliant devices. In order to avoid unnecessarily obscuring the 
present invention, the relationship between components 701-763 and the message flows between 
them are not shown. 

10 PCM CONFIGURATION AND Fl INfTf lOM 

Overview 

In one embodiment of the present invention, in HAVI network configurations where a FAV 
node is available, a DCM exists for each physical device in the HAVI network known about by 
15 that FAV node. The DCM provides an interface to the device and presents it as an object in the 
architecture. Other DCMs, system services or application services can query the local registry 
to find out the devices available and to get an identifier to allow them to interact with the devices 
via its DCM. 

» Device control modules are also responsible for interacting with the software 

architecture to present the device user interface (Ul) to the user. Input from users is then passed 
to the DCM which uses the input to control the actual device. 

As discussed above, DCMs support the level 1 and the level 2 interoperability. A level 1 
S DCM is a generic DCM, usually supplied with the FAV node, and capable of managing a basic, 
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pre-defined set of features of a device class using a pre-defined message set. During 
initialization, the DCM will work with the Device manager (below) to discover the actual 
characteristics of the device to be managed, and will configure itself to control that device. Thus 
a generic VCR controller could be instantiated to control a standard VCR using either 1394 
5 AV/C messages, or via Control A1. 

In the case of level 2 interoperability, the DCM instantiated for that device will be an 
override DCM that has been loaded from an external source, e.g. the device itself. These 
override DCMs are written in the common language format for DCMs. The functioning of an 
10 override DCM doesn't differ from generic ones but the API offered is likely to be more 
comprehensive. 

Once instantiated, DCMs will provide not only control interfaces for the device, but also 
access to SDD data associated with a device. They will act as event managers for a device, 
15 receiving device specific events and posting those to the event system (see below). They will 
also act as Ul manager for the device, interacting with the Ul management system to provide a 
user interface via some display device. Lastly, the DCM will operate as a resource manager for 
devices, arbitrating requests made for device access and service. 

20 General DCM terminology 

In the terminology of the present invention as used in the following descriptions, each 
DCM presents a model of a device in the home network. The basic terminology used is as 
follows: 
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1) Device: This term refers the entire device. 

2) Subdevice: This term refers to one of possibly many components that make up a 
device. Some technologies do not have the ability to distinguish subdevices. 

3) Internal Connection: This term refers to the logical or physical connection between 
5 internal subdevices. 

4) External Connection: This term refers to the connection between a physical 
connector on the outside of a device and a destination device outside the device. The same as 
unit Serial Bus and external input and output plugs for AV/C. 

5) Protocol: This term refers to the control protocol spoken by the sub-device or device 
10 (e.g., AV/C, Control A1 , etc.). It should be note that a device may contain subdevices which 

speak different protocols. 

6) Interface: This term refers to the physical bus connection interface (1394, USB, 

etc.). 

7) Device Class: This term is one way to describe the basic functionality of a given 
15 collection of devices. For example, the class of DVCR devices can record data to a tape 

medium. Likewise, there may be many devices that can take audio input, perform some kind of 
special effects, and output the modified audio stream. These would all come under the class of 
audio processor or something like that. The usefulness of this concept will become more apparent 
later in the document 

20 8) Device Model: This term refers to the collection of subdevices and connections that 

make up either a standard or custom device definition. Individual subdevices that are accessible" 
within physically separate devices can be combined to form logical or virtual devices using the 
device model. 
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9) Standard Device: This term refers to standard model definitions (e.g. a DVCR device is 
composed of at least a tuner subdevice and a VCR (transport) subdevice, with plugs between 
them). 

10) Special Device: This term refers to a vendor-specified device model, composed of 
5 either standard subdevices or a combination of standard and vendor-specific subdevices. For 

example, a dual deck DVCR may have two VCR subunits, which are standard items, but in a 
non-standard configuration. 

11) Aggregate devices: This term refers to logical entities which can be combined from 
a variety of components. Physical devices and subdevices are individually accessible pieces of 

10 hardware. When devices have accessible subdevices, this model is extended to support 

aggregate devices. Examples of aggregate devices include subdevices from separate physical 
devices or within a single device, and software modules such as software codecs which provide . 
services or capabilities similar to devices and subdevices. These modules can all reside in the 
same node on the AV network, or can be distributed among many nodes.. 

15 

Device classification 

Classifying devices based on the kind of actions they perform, or the kind of medium they 
deal with, is a way of allowing us to create a generalized control API that will work for devices 
that are created in the future. The intent is to allow a high percentage of basic functionality to 
20 always be accessible regardless of the type of device or the manufacturer of the device. 

Any manufacturer-specific or device-specific functionality that is controllable as well but 
falls outside of the generalized control API will only be accessible via the SDD information and 
other techniques for extending a DCM. 
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In the most general terms, the classification of devices or subdevices can be described by 
their main functionality. The AV/C control protocol of the 1394 standard uses a convenient 
method of classifying devices which we have adopted below. Following is the first set of factors 
used for classifying a device or subdevice: 



1) Whether a particular device has a transport mechanism. 

2) Whether the usefulness of this subdevice defined mostly by the fact that a signal ends 
up here (regardless of the fact that it may be propagated without changes). 

3) Whether a particular subdevice a signal source (e.g., does it have a signal output). 

4) Whether a particular device accepts input, performs some sort of processing, and 
then outputs modified data. 

5) Whether there is no signal input or output of any kind (e.g., is the device a utility of 
some kind, such as a mechanism for positioning a satellite antenna). 

In accordance with the present invention, at a second level of classification, we can 
study devices that contain a transport mechanism. In this case, a general question would be 
"does this device deal with removable media?". If it does, then a basic set of controls is applied, 
such as Play(), Stop() and even Search(). Devices with media can be queried for their ability to 
record, to determine the organization of information on the medium (is it track-based? continuous 
such as a tape? how is it measured - SMPTE time codes, time offset from a certain position, 
etc.). 

In the present embodiment, a signal processing service can be described by the kind of 
signal(s) it can accept, and the kind it can produce as a result. This requires the establishment 
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of common definitions for describing signal types and methods for accessing the services, so that 
any client can know how to describe what kind of service it is looking for, and how to access that 
service. 



Any device which accepts one kind of data and has the ability to transmit that data on a 
different type of connection (for example, it takes digital video as input and has standard analog 
video RCA jacks which can send that data back out) can act as a data converter class. The 
DCM for these devices will register itself as a data converter in the system registry, so that 
clients can find them and use them as necessary. 



10 



Device access and control 

In accordance with the present invention, once a basic device classification has been 
made, then the generic DCM instantiated for that device will provide an API that causes control 
messages to be sent to that device. The base set of control messages that can be sent or 
15 received (in the case of events) to a particular class of device are standardized and detailed in 
the appendix (not available in this version of the document). In the present embodiment, these . 
messages represent a basic API presented by the DCM. 



Device management 

20 In accordance with the present invention, the DCM API also provides a set of higher level 

services that allow more sophisticated management of the device. Examples of this include 
device reservation and event management. In the case of device reservation it is likely that a 
request for a device may be refused due to existing requests on the device, alternatively the 
device request may be for a future reservation for a time based macro. In these cases the DCM 
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provide an interface to allow an application or service to queue requests with the DCM, i.e. 
reserve a device, or to receive notification when a device becomes available. 

Connection management 

The DCMs of the present invention also provide a high level API to allow other objects to 
query the state of connections between devices and to manipulate those connections. This API is 
primarily used by the Route manager but is available to any object in the system. Connection 
management allows connections to be established, both internally between subdevice units, and 
externally between devices. Connection status can be queried and connection capabilities (signal 
formats) can also be queried. 
SDD management 

The DCMs of the present invention also provides a generalized interface to SDD 
management. This allows the SDD data in the device to queried and used. The API is divided 
into two parts, part 1 provides APIs for getting well know information from the SDD data 
including the Devicelrhage, its name and the URL (if available) of a location for an override DCM 
or other icons to be used in representing the device's Ul. Part 2 of the SDD API is designed to 
provide more detailed access to functional aspects of the device. 

Device representation and user interface fUl) 

In accordance with the present invention, the DCM is also responsible for the Ul aspects 
of the device. In the case of level 1 interoperability, a generic Ul is used to interface with users. 
This may be augmented by basic SDD data that allows such aspects as Ul icons to be specified 
and accessed by the generic DCM. In order to avoid unnecessarily obscuring the present 
invention, the details of how the DCM interacts with the Ul management system to present a 
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device specific Ul is not discussed in detail. In the present embodiment, however, the basic model 
is that internal management code within the DCM works with the Ul management system to 
present a Ul for the device. User input is then forwarded by the Ul management system, to the 
DCM which then converts it into device specific commands. These commands are sent, using the 
5 basic messaging system, to the device. If replies are received then these are passed via the 
DCM up to the Ul. In addition, any status changes of the device, e.g. on/off are also passed, via 
the evenlsystem ta the DCM which uses them to update the Ul. 

Service Modules 

10 Service modules (e.g., service modules 730) are conceptually similar to device control 

modules. They provide an interface to a service which is usually provided by software only. In 
the present embodiment, service modules are of two types, system services and application 
services. A system service is a well know service that is provided as part of the HAVI 
software architecture. Examples of these types of services are data format translators, 

15 protocol converters or graphics services. These services have well known APIs which are 
defined as part of the HAVI architecture. Application services are objects that have been 
created for and by other service objects. These objects provide a well defined API, however that 
API is not public. In the present embodiment, any application or other object that wishes to use 
an application object needs to know its API and calling semantics. Although not required, 

20 generally, system services will exist for the lifetime of the system. Application services will 
exist for the lifetime of an application and may be quite short lived. 

System services 

In accordance with the present invention, many of the services provided by the AV 
25 architecture are provided as service modules, who register their services in the system registry 
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and can be accessed using messaging. Examples of such services are the Ul service modules 
that provide a mechanism to allow devices to present a Ul to the user, data format services that 
convert AV data between different formats. 

5 THE PCM MANAGER 

Overview 

In accordance with the present invention, the DCM Manager is responsible for all aspects 
of handling the collection of DCMs resident on a FAV node. This includes the tasks of 

10 discovering, instantiating and disposing of ail possible device control module candidates that are 
available to a given system. Device resource management is generally carried out by individual 
DCMs, however, where multiple devices or services are interacting and where some of the DCMs 
are located on different FAV nodes, higher level management will be needed. Therefore, the 
DCM Manager communicates with other DCM Managers on remote nodes to arbitrate for 

15 network-wide device and subdevice resource allocation and management. Its responsibilities are 
discussed below. 

Discovery and enumeration of physical devices 

In accordance with the present invention, the DCM Manager works with the underiying- 
20 OS services to obtain a raw list of available devices. Note that depending on the underlying bus 
technology, these DCMs may be dynamic. In the present embodiment, for example, as physical - 
devices come and go on a 1394 bus the DCMs will come and go with them. In the same manner, 
the service and aggregate device DCMs are also dynamic, being created and destroyed in 
response to events in the FAV node. 
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This task requires interaction both with elements ot the AV architecture and also with 
elements of the FAV host OS, node hardware and communications hardware. Due to this, the 
exact process required for device discovery will depend on the system environment. However, 
5 the general approach, of querying a device and any SDD data it contains to discover its 
characteristics, as discussed in the DCM section, is common. In the present embodiment, this 
--requires the-BCM^^ sequence each time the system is 

initialized, or any time the system may change (such as when the bus is reset). 

10 Creation o{ Generic DCMs 

In accordance with the present invention, for each node, the DCM Manager does enough 
work to determine that it should create a DCM. This work is carried out for all media-related 
devices which will be managed by the FAV node. In the present embodiment, Devices under a 
different management technology, e.g. USB based devices, may be presented within the 
15 architecture as DCMs on nodes that support USB communication, or as special DCMs that act 
as proxies for a remote management system. It should be noted, however, that some USB- 
based devices such as hard disks may in fact be made to appear simply as random-access media 
recording or playback devices; in these cases, they are treated like any other "rear media 
device. In the present embodiment, for each media-related entity, the DCM Manager will create a 
20 generic or level 1 DCM. Each DCM will later have the responsibility to make itself more device- 
specific if possible. This is described below. 

Intp gratinn of level 2 DCMs 

In cases where an over-ride (e.g., level 2) DCM is available and accessible, the DCM 
25 manager is responsible for attempting to fetch that DCM and installing it into the FAV node. In 



WO 99/35753 PCT7US98/27758 

-43- 

the present embodiment,, the details of how the over-ride DCM and the generic DCM interact is 
dependent on the DCM developer. For example, in some cases it will completely replace the 
default DCM, in others it will work with the default DCM to augment its capabilities. 



5 In accordance with the present invention, manufacturer-supplied level 2 DCMs may come 

from a variety of sources. Devices may cany them within their ROM or some other storage 
mechanism such as the header of a disc or tape. They may be downloaded from a web or ftp 
site if such capabilities are accessible to the FAV node, or they could be supplied in the typical 
computer industry manner, via an installation from a disk or other storage medium. Allowing this 

10 manufacturer-supplied over-ride DCM capability requires a model for creating and installing 
DCMs. In the present embodiment, when installed, the level two DCM will provide the same base 
interface to the client as a level 1 DCM, while either providing additional interfaces or just 
underlying functionality modifications. 



15 DCM Disposal 

Jn accordance with the present invention, the DCM Manager will be responsible for 
disposing of DCMs at the appropriate times, and notifying clients that DCMs have been removed. 
In the present embodiment, the rules for when DCM disposal occur, and the distribution of 
responsibility for clean up, between the DCM and the DCM Manager, are tailorable to for the 

20 specific requirements of a particular HAVI network. 

Coordinate Amongst Multiple DCMs 

Some complex services among multiple DCMs, for example, command queuing of complex 
operations, etc., require the DCM Manager to coordinate with multiple DCMs to carry out these 
25 operations. This will be influenced by the "command model" that is provided for clients. For 
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example, if we define an upper level API that allows clients to specify actions that are based on 
HH:MM:SS:FF time codes, then we need to translate between this time model and whatever the 
hardware or underlying support modules deal with. It should be noted that complex time-based 
operations that are affected by mechanical delays, etc., need to be accounted for. This type of 
coordination requires some notion of real time behavior in the network and is dependent on the 
physical and software infrastructure providing some level of guarantee. 

Referring now to Figure 8. a layered logic diagram 800 of one HAVI architecture in 
accordance with the present invention is shown. The components shown in diagram 800 are 
similar to those shown in diagram 700, however, diagram 800 is organized such-that high level 
processes are on top (e.g., applications 801) with respect to lower level processes on the bottom 
(e.g., 1394 module 830). Diagram 800 also depicts other services 810, transportation adaptation 
modules 815, and other modules 840. 

As described above, the overall HAVI architecture can be shown as communications 
components and service components. Applications 801 . at the highest level in the architecture 
use the services and the communication components (e.g., DCMs 720, service modules 730, etc.). 
In turn, a number of the service components (e.g.. service modules 730, DCMs 720, etc.) will use 
the underlying communications components (e.g., messaging 702, transportation adaptation ■ 
) modules 815, etc.). For example, in the case of one of applications 801 requesting, via the 
registry 706, the handle for a DVTR (digital video tape recorder) device, and then sending a play 
command to the device. As described above, components in the HAVI architecture communicate 
using the underlying messaging system, i.e. the modules use message passing. 
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Figure 9 shows a diagram 900 of local and remote messaging in the HAVI architecture of 
one embodiment. The messaging component 702 is shown handling both local messaging and 
remote messaging. Hence the messaging component 702 is depicted at the base of diagram 900. 
Local messages are shown as arrows 902a, 903a, 904a, to various applications 901-904. A 
5 remote message is shown as arrow 901b. For the sake of clarity, in diagram 900 and in the 
following discussions, local communication via the messaging system is not depicted, rather, local 
messaging (e.g., arrows 901a-904a) are shown as if based on direct function calls between 
components. 

10 Figure 1 0 shows a diagram 1 000 of a message being sent via 1 394 in the HAVI 

architecture of one embodiment. In diagram 1000, message 1 (e.g., arrow 820a) is a request from 
one of applications 801 to the registry 706 (via the query API) for the handle of a DVTR device. 
The registry 706 returns a handle for the DVTR DCM in message 2 (e.g., arrow 820b). This 
handle is the message address used for the messaging system. 

15 

In accordance with the present invention the application then uses the handle to invoke 
the DCM for the DVTR with message 3 (e.g., 820c). The DCM converts the application 
invocation of the play call to an internal command which is sent to the messaging component, 
message 4 (e.g., arrow 820d). This internal command is part of the well defined command set at 

20 level 1 , i.e. it is a HAVI command. The messaging component 702 then internally uses the handle 
information to determine which bus this device resides on. When it discovers that it is on the IEEE 
1394 bus, it uses the IEEE 1394 transport adaptation module (TAM) 830 to convert the message 
to a 1394 packet, message 5 (e.g., arrow 820e), which is placed in the data portion of a FCP 
packet. The TAM then calls the 1394 device driver, message 6 (e.g., arrow 820f) to send the 

25 message over 1394. 
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At the receiving side (not shown), the message will be delivered to the 1394 device 
driver, and then passed up through a 1394 TAM to the Messaging component. The messaging 
component will receive a HAVI message packet which it will then deliver to the receiving code 
directly via a message queue or callback function. In the present embodiment, if the receiving 
device is an IAV device, it will only have the communications component of the CCEP 
architecture and the registry. Any other functionality it has will be device specific. 

It should be noted that the previous example in Figure 10 illustrates a distinction in the 
HAVI architecture between the messaging system and the command set used to control devices. 
In accordance with the present invention, the messaging system is a generic messaging 
mechanism that provides a message packet with a data section whose contents are completely 
opaque to the messaging system. For example, the messaging system can carry private 
application to application commands, AVC-CTS commands, CAL commands or any other 
command. The DCM is the entity responsible for communicating with remote devices, it uses the 
messaging system to carry commands specific to that device. For a level 1 HAVI compliant 
device, the command set carried by the messaging system is defined as part of the CCEP 
architecture. Messages carried by the messaging system between DCMs and devices they 
control contain these well defined commands. For level 2 devices the extended command set is 
undefined, these may be pure AV/C-CTS, CAL or any other commands. 

Referring now to Figure 11, a diagram 1100 of an application invoking another application 
in one embodiment of the HAVI architecture is shown. Diagram 100 shows an application 801a 
running on a device 1101 passing a message 1 105 to an application 801b running on a separate 
device 1 102 via messaging systems 702a and 702b. As described above, any application running 
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within the HAVI network can access any other application if it has a message handle for that 
application. To acquire a message handle, the same process is used as for a remote IAV device 
(e.g., described in Figure 10 above). Once a message handle is available, the source application 
801a can send a message 1 105' to the target application 801b. As described above, the format of 
5 these messages is entirely dependent on the application and is of no concern to the CCEP 
architecture. It simply provides a communication mechanism to send a receive messages 
between the applications. 

It should be appreciated that in the above example, it is assumed that the applications 
10 801 a and 801b reside on different AV devices 1 101 and 1 102. However, as discussed previously, 
it is quite possible that these applications 801a and 801b will reside on the same AV device and so 
the messaging system will perform a purely local communication call rather than a call that uses . 
1394 to transport the message. 

15 Invoking a software service 

A software service is a special case of the generic application case above. In 

accordance with the present invention, a software service is simply an application that is part of 

the system infrastructure. In this case, when a module wishes to invoke a system service, e.g. 

the Ul component, it uses the messaging component to do this. If the Ul component is local then 
20 the call is contained entirely within one AV device. However, if the Ul component is remote, then 

the call will be routed over the 1394 network to the remote AV device, where the message 

system will dispatch the call to the Ul system service. 



Adding a new device to a HAVI network 
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ln adding new devices to a HAVi network, there are 3 general situations: handling a 
legacy device using a legacy protocol carried over a non 1394 network; handling a base device 
using a non HAVI protocol over a 1394 network; and handling a new IAV device that is HAVI 
compliant. 

In the case of adding a legacy device, in the present embodiment, a legacy device can 
only be directly controlled by an FAV node. As described above, for each legacy device, a 
legacy DCM must be created. Consider an FAV that has a 1394 port and an Ethernet port. 
The CMM module will have been configured to manage both 1394 and Ethernet. When the legacy 
device becomes know to the FAV, it will first become known at the CMM module. Note that the 
mechanism used to achieve this is not within the scope of the CCEP architecture. It is 
communications media specific. Once the CMM recognizes a new device, it will go through 
whatever media specific mechanism it uses to determine the type of the device. Again this is not 
part of the CCEP architecture. Eventually it will ask the DM to instantiate a legacy DCM for 
this device. It is assumed that the FAV node has been pre-configured with this DCM. 

In the present embodiment, once the DCM is created, it registers itself in the same way 
as any standard DCM. However, one crucial difference between this DCM and other DCMs is 
that the communication model and the command set used to control the legacy device is 
completely unknown to the CCEP architecture. For example, it is possible that the device is an 
IP device that implements a printer service. In this case the DCM will provide a set of commands 
such as Print, Status etc. When an application calls the DCM API with a print request, the print 
command will be sent out by the DCM, via an IP stack, to the printer device. The actual details 
of how this happens are implementation specific. 
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In accordance with the present invention, one possibility is that the legacy DCM has a full 
implementation of the IP stack within the DCM and knows how to bind to the Ethernet device 
driver. Another possibility is that the FAV device provides an IP stack and a higher level API 
5 such as sockets. These are FAV implementation details and not part of the CCEP architecture. 
However, it should be noted that the legacy DCM is acting as a "proxy" DCM. Once it has been 
registered in the registry, it is visible to all other modules in the home network. They can all 
invoke its API and it performs.the necessary conversion to the private command language of the 
Ethernet IP printer. 

10 

In the case of adding a base AV device, in the present embodiment, when the CMM is 
informed about the new device, its recognizes that this is not a CCEP node, but it also discovers - 
that a DCM is available for this device. In this case, the CMM is responsible for implementing a 
mechanism that allows it to upload the DCM and to ask the DM to create this DCM. However, 

15 once the DCM is instantiated then it uses a purely private communication mechanism to access 
and control the device. As described above, in the present embodiment, a base AV device is one 
that uses 1394 and implements the over-ride DCM but does not implement any of the CCEP 
architecture and will not implement level 1 HAVI commands. An example of this device could be 
one that contains an over-ride DCM but does not support the CCEP communications 

20 infrastructure. 

In the case of adding an IAV device, it should be appreciated that in the previous 
examples, the application queried the registry to get a message handle for the device it wished to 
communicate with. Note that for a FAV device, the handle returned is always used to access 
25 the DCM. It is not possible to send messages directly to the device. To understand how a device 
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which is added to the network becomes available via the registry then the following example is 
used 

For example, assume a new device (e.g., a camcorder) is plugged into the HAVI network 
5 (e.g., 1394 based). This causes a bus reset. The bus reset is handled by the Communications 
media manager (CMM) on the IRD. The CMM is responsible for querying the SDD data of the 
_jCamcotder^evice4o^iscove^^^ a level 1 device - Le - il does 

not have, an uploadable DCM r then the CMM informs that Device Manager, that a new device 
has been installed. The Device Manager creates a new DCM for this type of device and 
10 registers the DCM with the registry. The DCM, when it initializes is free to query the device 
directly to find out more information about itself and to specialize itself if needed, e.g. it can 
access Ul information if it exists in the device. Once the DCM is registered in the registry, then 
any other module can query the registry to get a handle for the device and communicate with the 
DCM to access and control the device and present the Ul to the user. 

15 

For example, Figure 12A and 12 B show an exemplary Ul display (e.g., on a television 
screen) for such a device(e.g., the camcorder). Figure 12A shows a text menu display, where the 
user is presented with the various controls that can be modified using the control names and 
control values. For buttons, the user can select them (which equates to pushing a button). Figure 
20 12B shows a "next level" Ul display for the camcorder. Here, the user selected the main panel 
from the menu in Figure 12A, and the display presents controls based on their grouping 
information. In the present embodiment, group names are used on a tabbed interface to allow the 
user to navigate between groups within the selected panel. 
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Ref erring now to Figure 13, a flow chart of a process 1300 in accordance with one 
embodiment of the present invention is shown. Process 1300 shows the steps of a method for 
providing seamless interoperability and integration of a plurality of devices in a HAVI network by 
using the SDD information stored in each device. Process 1300 begins in step 1301, where a new 
5 device is coupled to a HAVI network. In step 1302, the device is queried to obtain a description 
(e.g., SDD) of level 1 functions supported by the device. In step, 1303, a level 1 DCM, which 
implements the level 1 functions, is generated for the device based upon the SDD. In step 1304, 
the device manager determines whether the new device contains software for a level 2 DCM. 

10 Referring still to Figure 13, in step 1305, if the new device contains software for 

implementing level 2 functions, the software is retrieved from the device and in step 1306, a level 
2 DCM which implements the level 2 functions is generated using the software. In steps 1307 and 
1308, the device is continually accessed via the level 2 DCM. In steps 1309 and 1310, if the new 
device does not include software for a level 2 DCM, the new device is continually accessed via 

15 the level 1 DCM. In this manner, the combination of the level 1 DCM and the level 2 DCM allow 
the present invention to provide seamless interoperability and integration of the new device with 
the plurality of devices in the network. 

Figure 14 shows a flow chart of a process 1400 in accordance with one embodiment of . 

20 the present invention. Process 1400 shows the steps of a method for providing a basic command 
functionality and an expanded command functionality between a plurality of devices in a HAVI - 
network. In step 1401, a device is coupled to a HAVI network which includes a FAV device. In 
step 1402, a generic level 1 DCM for the device is generated by the FAV device. As described 
above, the generic level 1 DCM is a basic abstraction of the capabilities of the device. The 

25 generic level 1 DCM enables the device to respond to a basic set of commands from the FAV 



PCT/US98/27758 

WO 99/35753 

-52- 

device. In steps 1403 and 1404, the FAV device uses the generic DCM to query the device to 
determine whether the device includes descriptive information (e.g., SDD). As described above, 
the descriptive information describes the capabilities of the device. In step 1405, if the device 
includes descriptive information, the FAV device generates a parameterized DCM for the device 
by modifying the generic DCM based upon the descriptive information. In steps 1406 and 1407, 
the device is continually controlled using the parameterized level 1 DCM. In steps 1408 and 1409 t 
if the~device-does-not include descriptive information, the FAV device is continually controlled via 
the generic level 1 DCM. 

Referring now to Figure 15, a flow chart of a process 1500 in accordance with one 
embodiment of the present invention is shown. Process 1500 shows the steps of a method for 
ensuring future upgradability and expandability of devices in HAVI network. In step 1501, a 
default level 1DCM for a device coupled to the network is generated. As described above, the 
default level 1 DCM is configured to ensure at least a minimum degree of interoperability between 
the device and the other devices on the HAVI network. In step 1502, the device is accessed by 
other devices via the default level 1 DCM. As described above, the default DCM enables the 
first device to respond to a default set of commands from other devices on the HAVI network In 
step 1503, an updated level 1 DCM for the devices is either received or not received. In step 
1504, updated level 2 DCM for the device is either received or not received. As described above, 
the updates enable the device's capabilities and functionality to evolve (e.g., as new, more 
efficient software becomes available). 

In steps 1509 and 1508, where an updated level.1 DCM is received, the updated level 1 
DCM is incorporated (e.g., this could involve merely modifying the current level 1 DCM) and the 
device is continually accessed- via this DCM until a later update is available. In step 1505, where 
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an updated level 2 DCM is received, the DCM manager on the host FAV device unlinks the 
current DCM, and in steps 1506 and 1507, the updated level 2 DCM is linked and the registry is 
updated to allow other devices within the HAVI network to access the updated level 2 DCM. 
This DCM is continually used for accessing the device until a later updated level 2 DCM is 
5 received. In step 1510, if neither an updated level 1 or an updated level 2 DCM is received, 
process 1500 continues operation with the current DCM (e.g., the last installed DCM). 



Figure 16 shows a flow chart of a process 1600 in accordance with one embodiment of 
the present invention. Process 1600 shows the steps of a method for providing seamless 

10 interoperability and integration of legacy devices with the HAVI compliant devices in a HAVI 
network. Process 1 600 begins in step 1 601 , where a legacy device is coupled to the HAVI 
network: In step 1602, the legacy device is queried via the proprietary protocol to determine a set 
of basic capabilities of the legacy device. As described above, HAVI compliant devices use a 
common HAVI defined protocol. The legacy device typically communicates with external 

15 devices (if at all) using a proprietary protocol. In step 1603, process 1600 maps a set of basic 
commands from the common protocol to the set of basic capabilities of the legacy device. In step 
1604, a level 1 DCM for the legacy device is generated. As described above, the DCM is based 
upon the set of basic commands. In steps 1605 and 1 606, the legacy device is continually 
accessed via the level 1 DCM such that the other HAVI devices are able to access the set of 

20 basic capabilities of the legacy device. 

Figure 17A shows a flow chart of a process 1700 in accordance with one embodiment of 
the present invention. Process 1700 shows the steps of a method of controlling devices within a 
home audio/video network using an application program from an external service provider. In 
25 step 1 702, an application program is originated by a service provider (e.g., via cable television, 
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internet web site, etc.). In step 1703, the service provider communicates the application program 
from the service provider to an intelligent receiver/decoder device of the HAVI network over a 
logical channel. The application is subsequently instantiated within a computer readable memory 
unit of the intelligent receiver/decoder. 

5 

Referring still to Figure 17A, in step 1704, the application program queries the HAVI 
registry of the device (e.g., FAV device) to locate DCMs on the network and selects a respective 
DCM from the registry. In step 1705, the down loaded application determines a communications 
point information from the selected DCM. In step 1706, the application controls a respective 
10 device of the HAVI network by communicating with the respective device using the 

communication point information. In step 1707, if the application needs to control another device, 
steps 1704 through 1706 are repeated. If the application does not need to control another device, 
processes 1700 ends in step 1708. 

15 Figure 17B shows a diagram of a HAVI network 1750 with the service provider 1720 in 

accordance with process 1700 of Figure 17A. As described above, the application program is 
downloaded from the service provider 1720 to the HAVI network 1750. The application is 
instantiated on the processor 601 and memory 602 of the intelligent device (e.g., set top box 301). 
HAVI network 1750 also includes four HAVI devices, device 0 through device 3 (e.g., television, 

20 DVTR, etc.). 

PCM MANAGEMENT API 

An example DCM management API in accordance with one embodiment of the present 
invention is shown below. In the present embodiment, the common DCM commands include areas 
25 such as connection management, information and status queries for the device and its plugs etc. 
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.Regardless of the type of device represented by the DCM f such message sets need to be 
supported. 



The following is a list of DCM management messages that, in the present embodiment, 
5 all DCM's need to support for the HAVI architecture: 



ChannelUsage(plug); // returns the 1394 isoch. channel used by the specified unit plug 
PlugUsage(channel); // returns the plug associated with the specified channel 

10 

GetDevicePlugCount(count); // returns the number of unit plugs on the device 
EstablishlntemalConnection(sourcePlug, destPlug); 
15 EstablishExternalConnection(sourcePlug, destPlug) 
StartDataFiow(plug); 
StopDataFlow(plug); 

20 

GetSourceConnection(in dest, out source); // given a destination plug, return the source to which 
it is connected (return the source plug of the transmitting device which shares the same isoch. 
channel) 

25 GetDestinationConnection(in source, out ); 
GetAIIConnection(); 
NotifyOnConnectionChange(); 

30 

GetDynamicConnectionCapability(); // report whether the target device supports dynamic 
connection changes or not (e.g., a non-I394 device) 

LockConnection(plug); 

35 

UnlockConnection(plug); 

GetConnectionStatus(plug); // status = busy, data transmission format, channel, bandwidth 
usage, etc. 

40 

BreaklntemalConnection(plug); 
BreakExternalConnection(plug); 
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GetlnputSignalFormat(plug); 
setlnputSignalForrnat(plug); 

5 

NotifylnputSignalFormat(plug); // send a notification if the signal format is changed. 

GetSupportedinputSignalFormats(plug); // repeat the above for output signals 

10 GetFunctionInfo(); // return information about the functional modules within the device (e.g., the 
AV/C subunits) 

- GetDeviceType(); ™ — ~ 

15 GetVendorName(); 

GetVendorLogoO; 

SetDevicePowerState(powerstate); 

20 

GetDevicePowerState(powerstate); 
GetSupportedPowerStates(list); 
25 NotiyPowerState(powerstate); 
ReserveDeviceQ; 
GetDeviceReservationStatus(); 

30 

NotifyDeviceReservationStatus(); 

VendorDependentCommand(command parameters); // pass thru a vendor-specific command 
in the native protocol; 

35 

Function Control Module (FCM) Messages; 

The function-specific messages correspond to the typical native commands such as 
PLAY, STOP, REWIND for the VCR functionality within a device. Because we need to address 
40 these messages to a well defined location within a device, we use the FCM (Function Control 
Module) to represent the target of these messages. Like DCM's, there are some messages that 
have to deal with administration and management of FCM's. These messages are supported by 
all FCM's, independent of their particular domain. The messages are as follows: 
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GetFunctionTypeO; II VCR, tuner, disc, etc. 

GetFunctionlnfoO; // more detailed information about the function, such as the particular kind of 
5 disc player (DVD, CD, etc.) 

GetNumberOfPlugs(inputPlugs outputPlugs); // returns the number of source and destination 
plugs for the functional module 

10 GetFunctionStatus(); // current status of the functional module, including the status of source 
and destination plugs (input and 
output) 

GetPowerState(powerState); // functional modules may have individually controllable power 
15 stcttos 

SetPowerState(powerState); 

GetSupportedPowerStates(list); 

20 

GetSupportedDataFormats(list); // returns the data formats supported by this functional module 

NativeCommand(params); // send the functional module a command in its native command 
protocol 

25 

The functional domain messages are based on the type of function (VCR, tuner, etc.). These are 
the typical PLAY, STOP, REWIND commands that one would expect. 



Level I interoperability includes both device-to-device and human-to-device interaction. 
30 The functional message sets such as PLAY, STOP and REWIND are used for device-to-device 
interaction. One example of this would be a video editing software package that wants to 
control any type of VCR; the program is designed with a very specific set of user interface 
controls which apply to all VCR's. When the user interacts with the application, the application in 
turn sends domain-specific commands such as PLAY and STOP to the target device. 

35 



• PCT/US98/27758 

WO 99/35753 

-58- 

In the HAVI architecture, the application will send these messages to the DCM, and the 
DCM will translate them into the native language of the target BAV device. If the target device 
happens to support the HAVI messaging architecture, then these commands don't need to be 
translated at all; they are simply sent as HAVI message to the HAVI target. 

Camcorder devices are essentially VCR like. Their additional functionality is part of the 
camcoiflef ef f eels ,Trarisitions,ltc7They are "aslollows: 



stop() 
10 play() 
rewindQ 
forward() 
record() 

volume(setvalue) 

15 changeStatus(newMode) // newMode of: VTR, CAMERA, STANDBY 

cameraControl(controrType) // controlTYPE defines control Type and subType structures eg 
zoom, zoomValue, or Effect, transitions etc. 

MiniDiscs are of the category random access storage, they support a base set of 
20 commands to control PLAY, FORWARD, etc and a set of command specific to random access 
media. The commands are as follows: 



stop() 
play() 
25 rewind() 
forward() 
record() 

volume(setValue) 

changeStatus(newMode) // newMode of: STANDBY 
30 seek(track) 
seekstart() 
seekEndO 

getDisklnfo() L t 

mdControl(controlType) // controlTYPE defines control Type and subType structures eg ii 

35 mode, random play. 
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Hard Disks are of the category random access storage, they support a base set of 
commands to control PLAY* FORWARD, etc and a set of command specific to random access 
media. The commands are as follows: 

5 

stop() 

Piay(L 

rewind() 

forward() 

10 record(type) // type structure passes info to allow intelligent devices to optimise storage policy 

changestatus(newMode) // newMode of: STANDBY 

seek(track) 

seek(block) 

seekStart() 
15 seekEndO 

HDDControl(controlType) // controlTYPE defines control Type and subType structures eg 
layout commands for block-structures 



With respect to user interfaces, it should be appreciated that a generic and simple Ul may 
20 be a textual based one, as shown in Figure 12A. A more sophisticated one, based on DCM 
specialization, may be as shown on figure 12B. Where graphical information, carried in SDD is 
used by the generic DCM to specialize itself. 



Hence, the present invention provides a home audio visual (AV) network which defines 
25 an open architecture for inter-operating CE (consumer electronic) devices in a home network. - 
The interoperability aspects of the present invention define an architectural model that allows 
CE devices from any manufacturer to inter-operate and function seamlessly within the user's 
home AV system. The system of the present invention includes acombination of a base set of 
generic device controls with an method to extend a base control protocol as new features and 
30 new CE devices are deployed within the home AV network. In so doing, the architecture of the 
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present invention is extensible, and can be readily modified and advanced as market requirements 
and technology change. 



The foregoing descriptions of specific embodiments of the present invention have been 
presented for purposes of illustration and description. They are not intended to be exhaustive or 
to limit the invention to the precise forms disclosed, and obviously many modifications and 
variations are possible in light of the above teaching. The embodiments were chosen and 
described in order to best explain the principles of the invention and its practical application, to 
thereby enable others skilled in the art to best utilize the invention and various embodiments with 
various modifications as are suited to the particular use contemplated. It is intended that the 
scope of the invention be defined by the Claims appended hereto and their equivalents. 
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CLAIMS 

What is claimed is: 

5 1 . A method of controlling devices within a home audio/video 

network, said method comprising the steps of: 

a) originating an application program at a service provider; 

b) communicating said application program from said service provider 
to an intelligent device of said home audio/video network; 

10 c) instantiating said application program within a computer readable 

memory unit of said intelligent device; 

d) said application program querying a name registry to obtain a 
communication point for a respective device control module, said name 
registry listing a plurality of device control modules supported within said 

1 5 home audio/video network; and 

e) said application program controlling a respective device of said 
home audio/video network by issuing commands to said respective device 
control module wherein said respective device is associated with said 
respective device control module. 

20 

2. The method as described in Claim 1 wherein said intelligent 
device is an intelligent receiver/decoder device and in step e) said 
application program controls a respective device of a plurality of devices of 
said home audio/video network. 

25 

3. The method as described in Claim 1 or 2 wherein said 
respective device is coupled to said intelligent device via a local bus. 

4. The method as described in Claim 1 or 2 wherein said 
30 intelligent device is a set-top-box. 
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5. The method of Claim 1 wherein said home audio/video network 
has a plurality of consumer electronic devices coupled to a local bus, said 
method being one of controlling said devices within said home audio/video 
network, wherein in steps d) and e) said respective device is a first device 

5 such that said application program queries a name registry to obtain a 
communication point for said first device control module, said name registry 
listing a plurality of device control modules supporting said devices within 
said home audio/video network; and said application program controls said 
first device of said home audio/video network by issuing commands to said 

1 0 first device control module wherein said first device is associated with said 
first device control module. 

6. The method as described in Claim 5 further comprising the 
steps of said application program querying said name registry to obtain a 

15 communication point for a second device control module; and said 

application program controlling a second device of said home audio/video 
network by issuing commands to said second device control module 
wherein said second device is associated with said second device control 
module. 

20 

7. The method as described in Claim 1 , 2 or 5 wherein said home 
audio/video network is a network of the home audio/visual initiative (HAVI) 
architecture. 

25 8. The method as described in Claim 3 or 7 wherein said local 

bus is of the IEEE 1394 standard. 

9. The method as described in Claim 5 wherein saia intelligent 
device is an intelligent receiver/decoder (IRD) device. 

30 

10. The method as described in Claim 5 wherein said intelligent 
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device is a digital television. 

1 1 . The method as described in Claim 5 wherein said service 
provider is a cable television provider. 

5 

12. The method as described in Claim 5 wherein said service 
provider is a satellite broadcast provider. 

13. The home audio/video network comprising: 
1 0 a local bus architecture; 

a plurality of devices coupled to said local bus architecture wherein 
one of said plurality of devices is an intelligent device comprising a 
processor, a bus, and a computer readable memory unit; 

said intelligent device for receiving an application program that 
15 originated from a service provider and for instantiating said application 
program within said computer readable memory unit of said intelligent 
device; 

said application program for querying a name registry to obtain a 
communication point for a first device control module, said name registry 
20 listing a plurality of device control modules supporting said plurality of 
devices coupled to said local bus architecture; and 

said application program further for controlling a first device of said 
plurality of devices by issuing commands to said first device control module 
wherein said first device is associated with said first device control module. 

25 

14. The home audio/video network as described in Claim 12 
wherein: said application program is also for querying said name registry to 
obtain a communication point for a second device control module; and 
wherein said application program is also for controlling a second device of 

30 said plurality of devices by issuing commands to said second device control 
module and wherein said second device is associated with said second 
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device control module. 

15. The home audio/video network as described in Claim 13 
wherein said local bus architecture is of the IEEE 1394 standard. 

5 

16. The home audio/video network as described in Claim 13 
wherein said intelligent device is an intelligent receiver/decoder (IRD) 
device. 

-10 17. The home audio/video network as described in Claim 13 

wherein said intelligent device is a digital television. 

18. The home audio/video network as described in Claim 13 
wherein said service provider is an internet web site and wherein said 

1 5 service provider and said intelligent device are coupled via the internet 

19. The home audio/video network as described in Claim 13 
wherein said service provider is a cable television provider. 



WO 99/35753 



PCT/US98/27758 



1/17 




FIG. 1A 



WO 99/35753 



PCT/US98/27758 



lob 



TELEVISION 
A 



2/17 




iH 



VIDEO 
CAMERA 



RECEIVER 



20 



2Z 
VCR UNIT 



SET TOP 
BOX 



CD 
UNIT 



FIG. IB 



WO 99/35753 



PCT/US98/27758 





HG.3 



WO 99/35753 



PCT/US98/27758 



4/17 




fig, 5 



WO 99/35753 



5/17 



PCTAJS98/27758 




FIG. 6 



PCT/US98/27758 

WO 99/35753 

6/17 



700 



Initialization 
Manager 

701 



720 



Device 
Modules 



T 



Messaging 



202 




730 



Registry 
7Q6 



High Level 
UI Library 

704 



740 



Service 
Modules 



Comms Media 
Manager 



Application 
(and User) 
Interface 
205 



750 



Communication 
Manager 



Device 
Manager 
261 




AV Actions/ 
Macro &ygg 



FIG. 7 



WO 99/35753 



PCT/US98/27758 



7/17 



800 







Applications 






720 

% 

DCMs 


/-n Service 
( /YModules 

730 


R 
e 

g 
i 

s 
t 
r 


Data 
Routing 


Comms 
Media 
Manager 


UI 

Components 


Other 
Services 


Device Manager 761 


y 

m 


2fi2 


m 


m 


W 



Messaging 
(A V Messenger) 

m 


Event 
Manager 

m 


Comms 
Manager 

750 


Transport Adaption Modules 


1394 


other 


other 







830 



FIG. 8 



WO 99/35753 



8/17 



PCTAJS98/27758 



900 




no. 9 



Messaging 
702 



WO 99/35753 



9/17 



PCT/US98/27758 



m © 


Applications 
r 820c © 820a©_ 82 0b 




DCMs 


720 


Service 
^^Modules 


tit 

e 

g 
i 
s 
t 
r 




Device Control Meager 



820d 
820e 



Messaging 

q ^ m 



Event 
Manager 

202 



Comms 
Manager 

m 



Transport Adaption Modules 




WO 99/35753 



PCT/US98/27758 



10/17 




T 

1105 



FIG. 1 1 



WO 99/35753 



11/17 



PCT/US98/27758 



Sony Model XYZ 5000 Digital VCR 

Main Panel 

J la y ; select 

Stop select 

r Fa5t Forwajd„„.„„ „.„„„. "..'.'".'.select 

,Jlewnd„„..„..„„„„_ 



To Main Menu 



Tp Editing Panel 



FIG. 12A 



r 



LCD Panel 



Device Control 



XYZ 5000 Digital VCR 



Play 




Stop 




Rew 




FF 



Main Menu 



< > 



Editing Panel 



FIG. 12B 



WO 99/35753 



PCT/US98/27758 



12/17 



Couple a new device to a 
HAVI network 



Query the new device to 
obtain a description of 
functions supported by the 
new device 



Generate a level 1 DCM for 
the new device based on the 
the description 




Determine whether the new 
device includes software 
code for a level 2 DCM 




Retreive the software code for 
the level 2 DCM 



i 



Generate a level 2 DCM for 
the new device using the 
software code 



Control the new device via the 
level 2 DCM 



I 



-J 



Control the new device 
via the level 1 DCM 



Continue 



Continue 



FIG. 13 



WO 99/35753 



PCT/US98/27758 



13/17 



Couple a device to a HA VI 
network 



Generate a generic level 1 DCM 
for the device 



I 



Query the device to determine 
whether the device includes 
descriptive information 




Descriptive information 
included? 



Generate a parameterized and 
specialized DCM by modifying 
the generic level 1 DCM 



Control the device using the 
parameterized DCM 



Continue 




Control the device 
using the generic 
level 1 DCM 



Continue 



FIG. 14 



WO 99/35753 



PCT/US98/27758 



U*0 



Us 



Incorporate the 
updated level 1 
DCM 



14/17 



Generate a default level 1 
DCM for a device 



\So\ 



Access the device via the 
default level 1 DCM 




Receive an updated 
level 1 DCM for the 
device? 




Receive an updated 
level 2 DCM for the 
device? 



Continue accessing the 
device using the current 
DCM 








Unlink the 
current DCM 



sJLink 



± 



the updated 
level 2 DCM 



VSt>7 



Update the 
registry 



Continue 
1 



FiGo 11 



WO 99/35753 



PCT/US98/27758 



15/17 



Add a legacy device to a 
HA VI network 



I 



Query the legacy device to 
determine a set of basic 
capabilities 



Map a set of basic 
commands to the set of 
basic capabilities of the 
legacy device 



\W3 



Generate a level 1 DCM for 
the legacy device based 
upon the set of basic 
commands 



Wo** 



Access the legacy device 
via the level 1 DCM 



\tOfc 



Continue 



FIG. 16 



WO 99/35753 



PCT/US98/27758 



16/17 



START 



APPLICATION PROGRAM ORIGINATED 

BY SERVICE PROVIDER 
(E.G., CABLE TV, INTERNET WEB SITE) 



SERVICE PROVIDER COMMUNICATES APPLICATION PROGRAM 
OVER A LOGICAL CHANNEL (E.G., CABLE TV, INTERNET) TO 

INTELLIGENT 

DEVICE OF HOME AUDIO/VIDEO NETWORK 



DOWNLOADED APPLICATION PROGRAM QUERIES REGISTRY 
OF INTELLIGENT DEVICE TO LOCATE DCMS AVAILABLE ON 
THE NETWORK AND SELECTS 
A RESPECTIVE DCM FROM THE REGISTRY 



DOWNLOADED APPLICATION PROGRAM DETERMINES 
COMMUNICATION POINT INFORMATION FROM THE 
RESPECTIVE DCM SELECTED 



I 



DOWNLOAED APPLICATION PROGRAM CONTROLS A 
RESPECTIVE DEVICE OF THE NETWORK BY COMMUNICATING 
WITH THE RESPECTIVE DEVICE USING THE 
COMMUNICATION POINT INFORMATION 



YES- 



FIG. 17 A 




O07 



WO 99/35753 



PCT/US98/27758 



17/17 



SERVICE PROVIDER 
(E.G., INTERNET WEB SITE, CABLE TV 
PROVIDER) 



U1& 



APPLICATION PROGRAM DOWNLOADED 



HOME AUDIOA/IDEO NETWORK 






INTELLIGENT DEVICE 
(EG., SET-TOP-BOX 
DIGITAL TV) 



PROCESSOR 



MEMORY' 



DCM 
REGISTRY 

DCMO 
DCM1 
DCM2 
DCM3 



7ot 



FIG. 17B 



. ' -I 




! 



I 



WORLD INTELLECTUAL PROPERTY ORGANIZATION 
International Bureau 




PCT 

INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(51) International Patent Classification 6 : 
H04L 12/28, 29/06 



A3 



(11) International Publication Number: 
(43) International Publication Date: 



WO 99/35753 

15 July 1999(15.07.99) 



(21) International Application Number: PCT/US98/27758 

(22) International Filing Date: 24 December 1998 (24.12.98) 



(30) Priority Data: 
09/003,412 



6 January 1998 (06.01.98) 



US 



(71) Applicant (for all designated States except US): SONY ELEC- 

TRONICS, INC. [US/US]; 1 Sony Drive, Park Ridge, NJ 
07656 (US). . 

(72) Inventor; and 

(75) Inventor/Applicant (for US only): LEA, Rodger, J. [-/US]; 210 
& 1/2 16th Street, San Jose, CA 951 13 (US). 

(74) Agents: GALLENSON, Mavis, S. et ah; Suite 2100, 9560 
Wilshire Boulevard, Los Angeles, CA 90036 (US). 



(81) Designated States: AL, AM, AT, AU, AZ, BA, BB, BG, BR, 
BY, CA, CH, CN, CU, CZ, DE, DK, EE, ES, FI, GB, GD, 
GE, GH, GM, HR, HU, ID, IL, IN, IS, JP, KE, KG, KP, 
KR, KZ, LC, LK, LR, LS, LT, LU, LV, MD, MG, MK, 
MN, MW, MX, NO, NZ, PL, PT, RO, RU, SD, SE, SG, 
SI, SK, SL, TJ, TM, TR, TT, UA, UG, US, UZ, VN, YU, 
ZW, ARIPO patent (GH, GM, KE, LS, MW, SD. SZ, UG, 
ZW), Eurasian patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, 
TM), European patent (AT, BE, CH, CY, DE, DK, ES, FI, 
FR, GB, GR, IE, IT, LU, MC, NL, PT, SE), OAPI patent 
(BF, BJ, CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, 
SN, TD, TG). 



Published 

With international search report. 

(88) Date of publication of the international search report: 

7 October 1999 (07.10,99) 



(54) Title: METHOD AND SYSTEM RELATED TO AN AUDIO/VIDEO NETWORK 



(57) Abstract 

A method and system for downloading applications 
for controlling devices within a home audio/video 
network. Several consumer electronics products, e.g., 
television, VCR, tuner, set-top box (e;g., intelligent 
receiver/decoder, 1RD), DVTRs, PCs, DVD players 
(digital video disk), etc., can be coupled within the 
network to communicate together via a standard bus (e.g, 
IEEE 1394 serial communication bus). In one 
embodiment, the HAVI network offers unique advantages 
consumer electronic vendors because the architecture 
offers for the home network many of the advantages of 
existing computer system networks. Namely, 
interconnected devices can share resources and provide 
open, well defined APIs that allow ease of development 
for third party developers. Devices are controlled using 
software abstractions of the devices or services called 
DCMs. The present invention provides a mechanism 
whereby applications can be downloaded, e.g., via a 
programmable intelligent device (e.g., set-top-box), and 
provide features and services within the network. These 
applications originate from a service provider, are 
transferred over a logical channel (e.g., the internet/TV 
cable, satellite broadcast) to the consumer premises and 
are instantiated on the intelligent device within the 
network. The application can query a registry of DCMs to 
determine its complement of functions and can ultimately 
control the devices of the network using the available 
DCMs. 



15QO 



Generate a Default Level 1 
DCM for a Device 



Access the Devfeevfa the ^ 1SflJ 
Default Level 10CM ^ 150Z 



t 



J^©3_>/R^^BnUrxlatedl^vej\f 
\ 1 DCM far the Device? / 



1503 



3E 



the Updated 
Level 1 
OCM 



< Receive an Updated LeveT^C 
k 2 DCM for the Qevtee? X 

F 



1504 



1509 



Continue Accessing 
the Device Using the 
Current OCM 



-1510 



Yes 



^1505 



UrtQnk the 
Current DCM 



•1508 



Unkthe 
L«&2DCM 



,-1507 



r 



If ... 1 



FOR THE PURPOSES OF INFORMATION ONLY 
Codes used to identify States party to the PCT on the front pages of pamphlets publishing international applications under the PCX. 



AL Albania 

AM Armenia 

AT Austria 

AU Australia 

AZ Azerbaijan 

BA Bosnia and Herzegovina 

BB Barbados 

BE Belgium 

BF Burkina Faso 

BG Bulgaria 

BJ Benin 

BR Brazil 

BY Belarus 

CA Canada 

CF Central African Republic 

CG Congo 

CH Switzerland 

CI Cote d'lvoire 

CM Cameroon 

CN China 

CU Cuba 

CZ Czech Republic 

DE Germany 

DK Denmark 

BB Estonia 



ES 

FI 

FR 

GA 

GB 

GE 

GH 

GN 

GR 

HU 

IE 

IL 

IS 

IT 

JP 

KE 

KG 

KP 

KR 

KZ 

LC 

U 

LK 

LR 



Spain 
Finland 
Prance 
Gabon 

United Kingdom 

Georgia 

Ghana 

Guinea 

Greece 

Hungary 

Ireland 

Israel 

Iceland 

Italy 

Japan 

Kenya 

Kyrgyzstan 

Democratic People's 

Republic of Korea 

Republic of Korea 

Kazakstan 

Saint Lucia 

Liechtenstein 

Sri Lanka 

Liberia 



L5 


Lesotho 


SI 


Slovenia 


LT 


Lithuania 


SK 


Slovakia 


LU 


Luxembourg 


SN 


Senegal 


LV 


Latvia 


sz 


Swaziland 


MC 


Monaco 


TD 


Chad 


MD 


Republic of Moldova 


TG 


Togo 


MG 


Madagascar 


TJ 


Tajikistan 


MK 


The former Yugoslav 


TM 


Turkmenistan 




Republic of Macedonia 


TR 


Turkey 


ML 


Mali 


TT 


Trinidad and Tobago 


MN 


Mongolia 


UA 


Ukraine 


MR 


Mauritania 


UG 


Uganda 


MW 


Malawi 


US 


United States of America 


MX 


Mexico 


UZ 


Uzbekistan 


NE 


Niger 


VN 


Viet Nam 


NL 


Netherlands 


YU 


Yugoslavia 


NO 


Norway 


ZW 


Zimbabwe 


NZ 


New Zealand 






PL 


Poland 






PT 


Portugal 






RO 


Romania 






RU 


Russian Federation 






SD 








SB 


Sweden 






SG 


Singapore 







INTERNATIONAL SEARCH REPORT 



ti lational Application No 

PCT/US 98/27758 



A. CLASSIFICATION OF SUBJECT MATTER 

IPC 6 H04L12/28 H04L29/06 



According to International Patent Classification (IPC) or to both national classification and IPC 



B. FIELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 

IPC 6 H04L H04N H04B 



Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched 



Electronic data base consulted during the international search (name of data base and, where practical, search terms used) 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 0 Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



CHILD J: "INTELLIGENT HOME TECHNOLOGY 
LOOKS FOR LEVERAGE FROM RELATED MARKETS" 
COMPUTER DESIGN, 

vol. 36, no. 12, 1 December 1997, pages 
85-87, XP000754856 

see page 87, middle column, line 30 - 
right-hand column, line 34 

EVANS G: "CEBus. Defining the future of 

residential communications" 

AUSTRALIAN ELECTRONICS ENGINEERING, MARCH 

1997, REED BUSINESS PUBLISHING, AUSTRALIA, 

vol. 30, no. 3. pages 34-36, 38. 

XP002105591 

ISSN 0004-9042 

see page 36, left-hand column, line 10 - 

middle column, line 7 

see page 38, left-hand column, line 4-10 

-/-- 



1,13 



1,13 



LU 



Further documents are listed in the continuation of box C 



□ 



Patent family members are listed in annex. 



* Special categories of cited documents : 

"A" document defying the general state of the art which is not 
considered to be of particular relevance 

"E" earlier document but published on or after the international 
filing date 

"L" document which may throw doubts on priority claim(s) or 
which is cited to establish the publication date of another 
■ citation or other special reason (as specified) 

"O" document referring to an oral disclosure, use, oxhtoition or 
other means 

"P" document published prior to the international filing date but 
later than the priority date claimed 



T" later document published after the international filing date 
or priority date and not in conflict with the application but 
cited to understand the principle or theory underlying the 
invention 

"X* document of particular relevance; the claimed invention 
cannot be considered novel or cannot be considered to 
involve an inventive step when the document is taken alone 

"Y" document of particular relevance; the claimed invention 
cannot be considered to involve an inventive step when the 
document is combined w9h one or more other such docu- 
ments, such combination being obvious to a person skilled 
in the art. 

"V document member of the same patent fam9y 



Date of the actual completion of the international search 



11 June 1999 



Date of mailing of the International search report 



08/07/1999 



Name and mailing address of the ISA 

European Patent Office, P.B. 5816 Patentlaan 2 
NL - 2280 HV Rijswijk 
Tel. (+31-70) 340-2040, Tx. 31 651 epo nl. 
Fax: (+31-70) 340-3016 



Authorized officer 



Dupuis, H 



Form PCT/tSA/210 (second sheet) (July 1092) 



INTERNATIONAL SEARCH REPORT 



In atlonal Application No 

PCT/US 98/27758 



C.(Contlnuatlon) DOCUMENTS CONSIDERED TO BE RELEVANT 



Category' I Citation of document, with indication, where appropriate, ot the relevant passages 



MARGOLIN B: "SMARTER STUFF" 
BYTE 

vol. '22, no. 6, 1 June 1997, page 85, 87, 
89, 91/92 XP000691560 
' see page 89 - page 92 



1,13 



Foim PCT/lSA/210 (continuation ol second snwt) (Jiiy 1092) 



VERSION* 



PCT 



WORLD INTELLECTUAL PROPERTY ORGANIZATION 
International Bureau 




INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(51) International Patent ClassIBcation 6 : 
H04L 12/28, 29/06 



A3 



(11) International Publication Number: WO 99/35753 

(43) International Publication Date: 15 July 1999 (15.07.99) 



(21) International Application Number: PCT/US98/27758 

(22) International Filing Date: 24 December 1998 (24.12.98) 



(30) Priority Data: 

09/003,412 



6 January 1998 (06.01.98) 



US 



(71) Applicant (for all designated States except US): SONY ELEC- 
TRONICS, INC. [US/US]; 1 Sony Drive, Park Ridge, NJ 
07656 (US). 

(72) Inventor; and 

(75) Inventor/Applicant (for US only): LEA, Rodger, J. [-/US]; 210 
& 1/2 16th Street, San Jose, CA 95113 (US). 

(74) Agents: GALLENSON, Mavis, S. et al.; Suite 2100, 9560 
Wilshire Boulevard, Los Angeles, CA 90036 (US). 



(81) Designated States: AL, AM, AT, AU. AZ, BA, BB, BG, BR, 
BY, CA, CH, CN, CU, CZ, DE, DK, EE, ES, FI, GB, GD, 
GE, GH, GM, HR, HU, ID, IL, IN, IS, JP, KE, KG. KP, 
KR, KZ, LC, LK, LR, LS, LT, LU, LV, MD, MG. MK. 
MN, MW, MX, NO, NZ, PL, PT, RO, RU, SD, SE, SG, 
SI, SK, SL, TJ, TM, TR, TT, UA, UG, US, UZ, VN, YU. 
ZW, ARIPO patent (GH, GM, KE, LS, MW, SD, SZ, UG, 
ZW), Eurasian patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, 
TM), European patent (AT, BE, CH, CY, DE, DK, ES, FI, 
FR, GB, GR, IE, IT, LU, MC, NL, PT, SE), OAPI patent 
(BF, BJ, CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, 
SN, TD, TG). 



Published 

With international search report. 

(88) Date of publication of the international search report: 

7 October 1999 (07.10.99) 



(54) Title: METHOD AND SYSTEM RELATED TO AN AUDIO/VIDEO NETWORK 



(57) Abstract 

A method and system for downloading applications 
for controlling devices within a home audio/video 
network. Several consumer electronics products, e.g., 
television, VCR, tuner, set-top box (e.g., intelligent 
receiver/decoder, 1RD), DVTRs, PCs, DVD players 
(digital video disk), etc., can be coupled within the 
network to communicate together via a standard bus (e.g, 
IEEE 1394 serial communication bus). In one 
embodiment, the HAVI network offers unique advantages 
consumer electronic vendors because the architecture 
offers for the home network many of the advantages of 
existing computer system networks. Namely, 
interconnected devices can share resources and provide 
open, well defined APIs that allow ease of development 
for third party developers. Devices are controlled using 
software abstractions of the devices or services called 
DCMs. The present invention provides a mechanism 
whereby applications can be downloaded, e.g., via a 
programmable intelligent device (e.g., set-top-box), and 
provide features and services within the network. These 
applications originate from a service provider, are 
transferred over a logical channel (e.g., the internet/TV 
cable, satellite broadcast) to the consumer premises and 
are instantiated on the intelligent device within the 
network. The application can query a registry of DCMs to 
determine its complement of functions and can ultimately 
control the devices of the network using the available 
DCMs. 



1500 



Generate a Default Lave) 1 
DCM for a Device 



Access the Device via the 
Default Level 1 DCM ^ 



Yes / Receive en Updated LeveTX^ 
\ 1 DCM for the Device? / 



1503 



the Updated 
Level 1 
DCM 



< Receive an Updated Level 
k 2 DCM for the Device? 



1504 



No 



-1505 



Continue Ac ce ssing 
the Device Using the 
Current DCM 



UnlMcthe 
Current DCM 



Link the 
Level 2 DCM 



( W1I 
I Continue j 



FOR THE PURPOSES OF INFORMATION ONLY 
Codes used to identify States party to the PCT on the font pages of pamphlets pub.ishing internal, app.ications under the PCT. 



AL 


Albania 


AM 


Armenia 


AT 


Austria 


AU 


Australia 


AZ 


Azerbaijan 


BA 


Bosnia and Herzegovina 


BB 


Barbados 


BE 


Belgium 


BF 


Burkina Faso 


BG 


Bulgaria 


BJ 


Benin 


BR 


Brazil 


BY 


Belarus 


CA 


Canada 


CF 


Central African Republic 


CG 


Congo 


CH 


Switzerland 


a 


C6te d'lvoirc 


CM 


Cameroon 


CN 


China 


CU 


Cuba 


CZ 


Czech Republic 


DE 


Germany 


DK 


Denmark 


EE 


Estonia 



E5 

FI 

FR 

GA 

GB 

GE 

GH 

GN 

GR 

HU 

IB 

IL 

IS 

IT 

JP 

KE 

KG 

KP 

KR 
KZ 
LC 
U 
LK 
LR 



Finland 
France 
Gabon 

United Kingdom 

Georgia 

Ghana 

Guinea 

Greece 

Hungary 

Ireland 

Israel 

Iceland 

Italy 
Japan 

Kenya 

Kyrgyzstan 

Democratic People's 

Republic of Korea 

Republic of Korea 

Kazakstan 

Saint Lucia 

Liechtenstein 

Sri Lanka 

Liberia 



LS 

LT 

LU 

LV 

MC 

MD 

MG 

MK 

ML 

MN 

MR 

MW 

MX 

NB 

NL 

NO 

NZ 

PL 

PT 

RO 

RU 

SD 

SE 

SG 



Lesotho 

Lithuania 

Luxembourg 

Latvia 

Monaco 

Republic of Moldova 

Madagascar 

The former Yugoslav 

Republic of Macedonia 

Mali 

Mongolia 

Mauritania 

Malawi 

Mexico 

Niger 

Netherlands 

Norway 

New Zealand 

Poland 

Portugal 

Romania 

Russian Federation 
Sudan 
Sweden 
Singapore 



SI 


Slovenia 


SK 


Slovakia 


SN 


Senegal 


sz 


Swaziland 


TD 


Chad 


TG 


Togo 


TJ 


Tajikistan 


TM 


Turkmenistan 


TR 


Turkey 


TT 


Trinidad and Tobago 


UA 


Ukraine 


UG 


Uganda 


. us 


United States of America 


uz 


Uzbekistan 


VN 


Viet Nam 


YU 


Yugoslavia 


zw 


Zimbabwe 



WO 99/35753 



PCT/US98/27758 



METHOD AND SYSTEM RELATED 
TO AN AUDIO/VIDEO NETWORK 

BACKGROUND OF THE INVENTION 
5 Field of the Invention 

The present invention relates to the field of communication systems. 
More specifically, the present invention relates to equipment for home 
audio/video electronics. One embodiment of the present invention is a 
method and system downloading applications for controlling devices within 
10 a home audio/video network. 

Related Art 

A typical home audiovisual equipment complement includes a 
number of components, e.g., a radio receiver, a CD player, a pair of 

1 5 speakers, a television, a VCR, a tape deck, etc. Components are connected 
to each other via sets of wires. One component is usually the central 
component of the home audiovisual system. This is usually the radio 
receiver, or the tuner/decoder. The control buttons and control switches are 
usually located on the front of the tuner and in many cases, some or all of 

20 these buttons and switches are duplicated on a hand held remote control 
unit. A user controls the home equipment by manipulating the buttons and 
switches on the front of the tuner, or alternatively, manipulating buttons on 
the hand held remote control unit. 

As consumer electronic devices have become more capable and 

25 more complex, demand for the latest and most capable devices has 

increased. As new devices emerge and become popular, new devices are 
purchased by consumers and "plugged 0 into their home audiovisual 
systems. The new device is simply plugged into the system alongside the 
pre-existing, older devices (e.g., cassette tape deck, CD player, and the like). 

30 The new device is plugged into an open input on the back of the tuner, or 
some other device coupled to the tuner. The consumer 
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(e.g., the user) controls the new device via control switches on the new device itself, or via a 
separate remote control unit for the new device. 

As the number of new consumer electronics devices for the home audiovisual system has 
grown and as the sophistication and capabilities of these devices have increased, a number of 
5 problems with the conventional paradigm emerge. One such problem is incompatibility between 
devices in the home audiovisual system. In addition, where one device is much newer than 
another device additional incompatibilities may exist. For example, a new device might 
incorporate hardware (e.g., specific inputs and outputs) which enables more sophisticated remote 
control functions. This hardware may be unusable with older devices within the system. Another 
10 problem is the lack of functional support for differing devices within an audiovisual system. For 
example, even though a television may support advanced sound formats (e.g., surround sound, 
stereo, etc.), if an older less capable tuner does not support such functionality, the benefits of- the 
advanced sound formats can be lost. Another problem is the proliferation of controls for the new 
and differing devices within the home audiovisual system. Each new device coupled to the 
15 audiovisual system often leads to another dedicated remote control unit for the user to keep 
track of and learn to operate. 

The conventional audiovisual system can also include a set-top-box. A set-top-box of th« 
prior art is an intelligent receiver (decoder) that typically is used to supply an audio/video signal 
from a service provider to a television. The set-top-box generally performs a number of 
20 descrambling or decoding functions. It is possible to download very basic commands from the 
service provider that are executed within the set-top-box to provide very simple features or 
services to the consumer. Typical applications of this are a command set that enhances a videc 
news clip displayed on a television with extra textual and/or graphics information that can be 
overlaid on the video news clip if requested. Also available is a home shopping service that 
25 allows a consumer to choose and purchase a service of goods by using a simple indicator. 
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However, these applications merely reside on and interact only with the television (or data entry 
device) directly coupled to the set-top-box and do not allow control of any other devices of the 
home audiovisual system. 
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SUMMARY OF THE INVENTION 

Accordingly, the present invention provides a system allowing improved interoperability 
within consumer audio/visual electronics products of a home system. The present invention 
further provides a system and method within a home audio/visual network that allows for 
5 expanded functionality for set-top-box applications. Specifically, the present invention offers a 
method and system for allowing devices of a home audio/video network to be controlled by one or 
more downloaded application programs originating from a service provider. 

A method and system- are described for downloading applications for controlling devices 
within a home audio/video network. Several consumer electronics products, e.g., television, VCR, 
10 tuner, set-top box (e.g., intelligent receiver/decoder, IRD), DVTRs, PCs, DVD (digital video disk) 
players, etc., can be coupled within the network to communicate together via a standard bus 
(e.g., IEEE 1394 serial communication bus). This allows devices of the network to control one 
another and obtain information regarding one another. In one embodiment, the communication 
architecture used is the home audio/visual initiative (HAVI) format. The HAVI network offers 
15 unique advantages because the architecture offers for the home network many of the 

advantages of existing computer system networks. Namely, interconnected devices can share 
resources and provide open, well defined APIs that allow ease of development for third party 
developers. HAVI offers extended interoperability. 

In the home environment, one requirement for consumer electronics is ease of set-up of 
20 devices by the consumers. This requires that a consumer can plug a device into the home 
network and have the home network and the device automatically configure themselves to 
ensure that the new device can be accessed and used. To ensure this, the present invention 
includes a home environment software architecture that allows any new device to be queried. 
Then a software abstraction of that device is created and made available to other elements in 
25 the network. Since it is likely that over the lifetime of the system, new devices will be added 
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whose capabilities and features are yet unknown, or only partially known to other devices, the 
present invention provides a mechanism that guarantees that all devices can be communicated 
with and controlled at some basic level. Thereafter, where possible, e.g., as more information is 
obtained about the device, a better abstraction of the new device is created by the present 
5 invention. 

A DCM or device control module is the software abstraction used by the present 
Invention to control devices within the home audio/video network. The DCM is a software 
abstraction of a device or service and provides an interface to that device. DCMs are hosted by 
intelligent nodes of the home audio/video network. Some devices, such as a set-top-box 

10 (intelligent receiver/decoder) or digital television act as both devices in the home network, 
communicating with other devices, and as gateways to external service providers (e.g., the 
internet, digital TV provider, cable provider, etc.) outside of the home. 

In the set-top-box of the present invention it is possible to download one or more 
application programs from a service provider that are run on the set-top-box. The application 

15 program generally is intended to provide some features or services to the home network. As a 
device on the home network of the present invention, the set-top-box has access to other devices 
in the home network. Therefore, the present invention allows the creation of downloadable 
applications that are transmitted from a service provider (e.g., a cable television provider, an 
internet web site, a telephone or other land line utility, a satellite broadcast service, etc.) to the 

20 consumer premises and instantiated on the set-top-box. In this case, the application programs 
can interact within the home network. 

Facilitating this functionality, the present invention provides a generic method of making 
available services and devices that are present in the network. The present invention registers 
the DCMs of the devices in the home network into a registry or name server. The home network 

25 of the present invention then provides a mechanism to allow any new downloaded application to 
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query this registry and receive back a communication end point for the DCM. The downloaded 
application is then provided with a mechanism to send requests to the DCM that are used to 
interact and control the actual devices of the home network. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is illustrated by way of example and not by way of limitation, in 
the figures of the accompanying drawings and in which like reference numerals refer to similar 
elements and in which: 

5 

Figure 1 A shows a home AV network in accordance with one embodiment of the present 
invention. 

Figure 1 B illustrates a logical bus configuration of the HA VI network of Figure 1 A. 

10 

Figure 2, shows an exemplary peer to peer, two IAV (intermediate audio video) node 
network in accordance with one embodiment of the present invention. 

Figure 3 shows a single FAV (full audio video) cluster HAVI network in accordance with 
15 one embodiment of the present invention. 

Figure 4 shows an FAV cluster integrated with an IAV peer to peer HAVI network. 

Figure 5 shows an exemplary HAVI network having multiple FAVs. 

20 

Figure 6 shows a diagram of a set top box in accordance with one embodiment of the ■ 
present invention. 



25 



Figure 7 shows a logical block diagram of one embodiment of the HAVI architecture of 
the present invention. 



WO 99/35753 



-8- 



PCT/US98/27758 



Figure 8 shows a layered logic diagram of one HAVI architecture in accordance with the 
present invention. 

5 Figure 9 shows a diagram of local and remote messaging in the HAVI architecture of one 

embodiment 

Figure 10 shows a diagram of a message being sent via 1394 in the HAVI architecture of 
one embodiment 

10 

Figure 11 shows a diagram of an application invoking another application in one 
embodiment of the HAVI architecture. . 

Figure t2A shows a first exemplary Ul display (e.g., on a television screen) for a device 
15 (e.g., the camcorder). 

Figure 1 2B shows a second exemplary Ul display (e.g., on a television screen) for a 
device(e.g., the camcorder). 



20 



Figure 13 shows a flow chart of a process for providing seamless interoperability and 
integration of a plurality of devices in a HAVI network by using the SDO information stored in 
each device in accordance with one embodiment of the present invention. 
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Figure 14 shows a flow chart of a process for providing a basic command functionality 
and an expanded command functionality between a plurality of devices in a HAVI network in 
accordance with one embodiment of the present invention. 

Figure 15 shows a flow chart of a process for ensuring future upgradability and 
expandability of devices in HAVI network in accordance with one embodiment of the present 
invention. 

Figure 16 shows a flow chart of a process for providing seamless interoperability and 
integration of legacy devices with the HAVI compliant devices in a HAVI network in accordance 
with one embodiment of the present invention. 

Figure 17A shows a flow chart of a process for controlling devices within a home 
audio/video network using an application program from an external service provider accordance 
with one embodiment of the present invention. 

Figure 17B shows a diagram of a HAVI network with the service provider in accordance 
with the process of Figure 17A. 
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pFTAILED DESCR Y™ ™ ™E INVENTION 

Reference will now be made in detail to the embodiments of the invention, examples of 
which are illustrated in the accompanying drawings. While the invention will be described in 
conjunction with the preferred embodiments, it will be understood that they are not intended to 

5 limit the invention to these embodiments. On the contrary, the invention is intended to cover 
alternatives, modifications and equivalents, which may be included within the spirit and scope of 
the invention as defined by the appended claims. Furthermore, in the following detailed description 
of the present invention, numerous specific details are set forth in order to provide a thorough 
understanding of the present invention. However, it will be obvious to one of ordinary skill in the 

10 art that the present invention may be practiced without these specific details. In other instances, 
well known methods, procedures, components, and circuits have not been described in detail as 
not to unnecessarily obscure aspects of the present invention. 

The present invention provides a home AV network which defines an open architecture 
15 for inter-operating CE devices in a home network. The interoperability aspects of the present 
invention define an architectural model that allows CE devices from any manufacturer to inter- 
operate and function seamlessly within the user's home AV system. The system of the present 
invention includes a combination of a base set of generic device controls with an method to 
extend a base control protocol as new features and new CE devices are deployed within the 
20 home AV network. In so doing, the architecture of the present invention is extensible, and can be 
readily modified and advanced as market requirements and technology change. The present 
invention and its benefits are further described below. 



NOTATION AND NOMENCLATURE 
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Some portions of the detailed descriptions which follow are presented in terms of 
procedures, steps, logic blocks, processing, and other symbolic representations of operations on 
data bits within a computer memory (see Figure 2). These descriptions and representations are 
the means used by those skilled in the data processing arts to most effectively convey the 
5 substance of their work to others skilled in the art. A procedure, computer executed step, logic 
block, process, etc., is here, and generally, conceived to be a self-consistent sequence of steps or 
instructions leading to a desired result. The steps are those requiring physical manipulations of 
physical quantities. Usually, though not necessarily, these quantities take the form of electrical 
or magnetic signals capable of being stored, transferred, combined, compared, and otherwise 

10 manipulated in a computer system. It has proven convenient at times, principally for reasons of 
common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, 
numbers, or the like- 
It should be borne in mind, however, that all of these and similar terms are to be 

15 associated with the appropriate physical quantities and are merely convenient labels applied to 
these quantities. Unless specifically stated otherwise as apparent from the following discussions, 
it is appreciated that throughout the present invention, discussions utilizing terms such as 
"processing" or "computing" or "translating" or "instantiating" or "determining" or "displaying" or 
"recognizing" or the like, refer to the action and processes of a computer system, or similar 

20 electronic computing device, that manipulates and transforms data represented as physical 
(electronic) quantities within the computer system's registers and memories into other data 
similarly represented as physical quantities within the computer system memories or registers or 
other such information storage, transmission or display devices. 
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ARP.HITFCTURE OVERVIEW 

The Architecture of the present invention enables the creation of a Home AV system 
which provides for seamless support of new devices and problem free interoperability of devices 
in a home AV network. The most basic components of a system in accordance with the present 

5 invention are: a home AV interoperability architecture, a series of home AV interoperability 
interfaces, and a home AV network. The home AV interoperability architecture is a broad, over 
arching term encompassing the physical network and the controlling programming interfaces. 
Interoperability interfaces is a. term used to describe the interactions and interfaces of the 
components of the AV architecture. In addition to providing a common command set, the 

10 interoperability interfaces provide a software architecture which allows new devices to be 
integrated into the network and provide their services in a seamless manner. The home AV 
network is the term used to describe the physical network and its topology. 

It should be noted that the home AV interoperability (HAVI) architecture of the present 
15 invention is an open, platform-independent, architecturally-neutral network that allows consumer 
electronics manufacturers and producers to provide inter-operable appliances. It can be 
implemented on different hardware/software platforms and does not include features that are 
unique to any one platform. The interoperability interfaces of the HAVI architecture are 
extensible and can be added to, modified and advanced as market requirements and technology 
20 change. They provide the infrastructure to control the routing and processing of isochronous and 
time-sensitive data (e.g., such as audio and video content). 

Specifically, the HAVI architecture provides: an execution environment supporting the 
visual representation and control of appliances; application and system services; and 
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communication mechanisms for extending the environment dynamically through plug and play or 
otherwise. 

It should be noted that the HA VI architecture supports legacy appliances (e.g., appliances 
5 that already exist and are available to users). This is important since the transition to more 
intelligent networked appliances is going to be slow. Most manufacturers will not suddenly begin 
producing only "intelligent" appliances and most consumers will not quickly begin replacing all of 
their existing appliances. 

10 In accordance with the present invention, there are two classes of legacy appliances. A 

first class includes "one-way" or unacknowledged control appliances. A second class includes 
controllable "two-way" appliances. Examples of one-way appliances are audio/video components 
controlled by infrared commands of a hand held remote. Two-way appliances provide 
confirmation of command execution, status and error reporting. Examples of two-way appliances 

15 include the recent introduction of well known IEEE 1394 enabled digital cameras. 

It should be noted that the home AV network (hereafter HAVI network) of the present 
invention provides support to accommodate future appliances and protocols through a write-once, 
run-everywhere common language. In accordance with the present invention, each appliance 
20 includes within it self-describing information concerning the user interface and the device control 
that can be used by an external controller. This information is specified as programs in the 
common language. 



25 



As described below, the underlying structure for such a network consists of set of 
interconnected clusters of appliances. Typically, there will be several clusters in the home, with 

SONY-50L2284 
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one per floor, or per room. Each cluster will work as a set of interconnected devices to provide a 
set of services to users. Often, one device will act as a controller for a set of other devices. 
However, the architecture is sufficiently flexible to also allow a home to consist of a single 
cluster with no master controller. 

5 

For example, in one embodiment of the present invention, an intelligent television in the 
family room of a user's home might function as the controller for a number of interconnected 
appliances. Each of the controlled appliances would have self describing data and possibly some 
associated control code. When these appliances are first connected, the controller obtains the 

10 user interface and the control program for the appliance. An icon representing the appliance may 
then appear on the television screen, and manipulating the icon may cause elements of the control 
program to actuate the represented appliance or appliances in prescribed ways. The exception 
to this model are legacy devices which will have neither self describing data or control code. For 
addition descriptions and related art regarding self describing data, the reader is referred to 

15 Ludtke, et al., A METHOD AND APPARATUS FOR INCLUDING SELF-DESCRIBING 

INFORMATION WITHIN DEVICES, provisional application number 60/054,327, filed on July 31, 
1997, which is incorporated herein by reference. 

It should be noted that the HAVI network of the present invention supports "Plug and 
20 Play" consumer appliances are easy to install, and provide a significant portion of their value to 
the consumer without any action on the user's part, beyond physically connecting the cables. 
This is in distinction to existing appliances that require configuration to provide some major 
portion of their functionality. The goal is to offer 'hot' plug and play (not requiring the user to 
switch off appliances) where the connection method supports it safely and reliably. 
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In accordance with the present invention, an appliance configures itself, and integrates 
into a system-wide "look and feel" user interface, without user intervention. Low-level 
communication services provide notification when a new appliance is identified on the AV 
5 network. While there will often be settings the user may change to suit his or her preferences, the 
appliance does not require the user to do so in order to offer basic functionality. 

It should also be noted that the HAVI network of the present invention is flexible and 
supports multiple user interfaces, adapting to both the user's needs and the manufacturers.need 

10 for brand differentiation. In the AV network, protocols scale gracefully from very resource-rich, 
intelligent PC-like appliances to "dumb", resource starved appliances (e.g., a coffee maker or 
thermostat). To achieve this, the AV architecture allows low-end appliances to use the 
resources of more intelligent appliances in well-defined ways. In a similar manner, the AV 
architecture allows the specification of aggregate appliances where an abstract appliance is 

15 created from a logical collection of several lower-level appliances. 

And additionally, it should be noted that the HAVI network of the present invention 
supports existing standards. The HAVI network is complementary to several existing, well 
known, industry standards and technologies including: CEBus; Home Plug and Play; EHSI; 
20 VESA; Home Network, DAVIC, CoMMeND, Lonworks, USB, IEEE 1394, etc. Accordingly, one 
goal of the present invention is to provide an infrastructure into which existing devices can fit. 



25 



THE SYSTEM MODEL OF THE HAVI ARCHITECTURF 

With reference now to Figure 1A, a HAVI network 10a in accordance with one 
embodiment of the present invention is shown. As described above, the HAVI architecture 
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supports a wide range of devices including intelligent receiver/decoders (IRDs), for example, the 
set top box 301, digital video tape records (DVTRs), video cassette recorders (VCRs), personal 
computers (PCs), digital video disk players (DVDs), etc., communicating via a common 
messaging system. Figure 1A illustrates the physical port-to-port connecting configuration 10a of 
5 an exemplary HAVI network. CE devices ("devices") 12-24 are shown connected together with 
bus segments 30a-30f. In one embodiment of HAVI, the IEEE 1394 serial communication bus 
standard is used as a platform. to. provide .the common messaging system. 

Figure 1B illustrates a logical bus configuration 10b of the HAVI network of Figure JA. 

10 As shown in Figure 1B, all of the devices 12-24 of the HAVI network can be viewed as logically 
coupled to a common IEEE 1394 serial communication bus 30. Within this bus configuration 10b, 
peer-to-peer device communication is supported. For example, as shown in Figure 1C, any device 
(having appropriate capabilities), e.g., device 12, can send or receive communication packets from 
any other device in the HAVI network. In the example of Figure 1B, the set-top-box (e.g., an IRD) 

15 can receive messages from or generate messages to any of the other devices 14-24 of the HAVI 
network. 

Referring still to Figures 1 A and 1 B, as described above, the interoperability model in 
HAVI provides for the following: 1) support for existing devices; 2) a default control model; 3) a 
20 means to extend the default control model when new devices or functionality is brought to 
market; and 4) a common means for device representation (e.g., graphics user interfaces). To 
achieve the above, the HAVI architecture defines three types of nodes inlhe home network: Full 
AV nodes (FAV), Intermediate AV nodes (IAV) and Base AV nodes (BAV). 



WO 99/35753 PCT/US98/27758 

-17- 

A Full AV node is a device that contains a complete instance of the AV software model 
(described in detail below). This type of node generally has a richer set of resources and is 
capable of supporting a complex software environment. The primary distinguishing feature of a 
FAV is that it is able to take control responsibility for less sophisticated devices and does this by 
5 loading a control module, usually from the less sophisticated device, and executing it locally. 
Examples of such nodes would be Set Top Boxes (e.g., set top box 301), Smart TV's, general 
purpose home control devices, or even Home PC's. 

Intermediate AV.nodes are generally lower cost devices that have limited resources. 

10 They do not provide an execution environment for control modules and so can not act as master 
controllers within the home network. Because they have limited resources, they can access 
remote resources in one of two ways: by working with other IAV devices who provide some . 
capability they lack, or by using an FAV node which supports a control module to control them. In 
this second mode of operation they rely on full AV nodes to provide such facilities as a display 

15 device, general purpose compute resources and some overall control framework. This allows Full 
AV devices to bind a variety of intermediate AV devices together to provide a service or 
abstraction to the user. 

Base nodes are nodes that are neither FAV or IAV nodes. These are two generic types: 
20 Legacy base nodes, and other base nodes. Legacy base nodes are devices that were built before 
the advent of the HAVI architecture. These devices often use proprietary protocols for their 
control, and quite frequently have a simple, well defined, control only protocol. Such devices can 
work in the HAVI network but require that a Full AV node act as a gateway. Communication 
between a Full or Intermediate AV node and legacy devices requires that the Home AV 
25 commands used in the HAVI architecture be translated to and from the legacy command 
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protocol. Other base nodes are devices that, for business or resource reasons, choose to 
implement future proof behavior using uploadable control software and do not carry any of the 
HAVI architecture or the message communication system. These devices will be controlled by an 
FAV node with a private command protocol between FAV and BAV node. 

5 

With the exception of legacy nodes, each node has, as a minimum, enough functionality to 
allow it to communicate with other nodes jn the.system....D.uring the course of interaction, nodes 
exchange control and data information to enable devices to inter-operate and will do so in a peer 
to peer fashion. This ensures that, at the communication level, no one device is required to act 
10 as a master or controller for the system. However, it also allows a logical master or controller 
to impose a control structure on the basic peer to peer communication model. Services in the 
HAVI network are provided by one or more nodes communicating amongst themselves to deliver 
a service to user or an application. Where it is necessary for a node to interact with a user, then 
the node negotiates with other nodes to access and use a display device. 

15 

Additionally, it should be appreciated that a distinction is made between Logical and 
Physical nodes. A good example of this distinction can be found in a normal TV set. Although the 
TV set is generally one physical box, it contains several functional components, e.g. the tuner, 
audio output etc. From the system point of view a physical node is an addressable peer node in 
20 the system. If the TV is constructed in such a way that its individual functional components are 
individually addressable, then it is logically one node and physically several nodes. Conversely, il 
it is constructed to have one addressable entity, then it is both a single logical node and a single 
physical node. 
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The IAV devices and FAV devices communicate by sending messages over the home 
network using a generic message passing system. When new devices join the home network, they 
are recognized and added to a global name database (registry). The registry holds information 
about their characteristics and provides a reference to a handler for that device. Other devices 
5 and services are able to query the registry to locate a device and then using the handler, can 
interact with the device. For additional descriptions and related art regarding the communication 
and identification processes of the present invention, the reader is referred to Ogino, et al., 
"METHOD AND SYSTEM FOR PROVIDING A DEVICE IDENTIFICATION MECHANISM 
WITHIN A CONSUMER AUDIO/VIDEO NETWORK", a US patent application filed on 6, Jan, 
10 1 998, which is incorporated herein by reference. 

When a device is initially added to the home network, the system queries the device to 
ascertain its characteristics and capabilities. Once a device's characteristics are known, the 
architecture provides two methods of controlling it. The first method, level 1 interoperability uses 
15 a predefined message set. All IAV and FAV nodes can use this command set to access and 
control other devices (BAV nodes, because they are deployed before the architecture was 
defined, are controlled using legacy protocols). The provides a default level of control The FAV 
nodes act as control nodes and create a local representation of the IAV node, known as a device 
control module (DCM) that provides an API used to send control commands to the device. 

20 

Level 2 interoperability within HAVI goes farther and supports future added functionality 
and new devices. To achieve this, a particular device can carry within its ROM, an override 
DCM that is uploaded from the IAV device, to the FAV device and replaces the default DCM for 
the particular device. This override DCM not only contains the basic level 1 command set for the 
25 particular device but also includes vendor specific commands to control advanced features of the 
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device. The model allows the device to inform another about its particular functionality. Since 
the override DCM may be loaded onto any vendor's FAV, the format of the DCM is 
architecture-neutral. 



5 To allow one device to discover the capabilities of another device and to determine which 

. command set to use with that device, a standard device description structure is provided called 
_^selfd^bingjja ta (SD D) structure. The SDD data structure is extensible. It can be a 
small number of bytes describing the device type, e.g., TV, or VTR, etc. Alternatively, the SDD 
data structure can be a more complex structure also defining the override DCM and a graphical 

10 representation of the device. The graphical representation within the SDD data structure allows 
an FAV node to present a pictorial representation of the devices in the home network to users. 
By defining the graphical representation in a sufficiently generic manner, a device's SDD 
graphical data can be used in any vendor's product to display a user interface for that device. 
This provides an enhanced level of vendor interoperability and also allows a vendor to 

15 differentiate a product while maintaining within the general look and feel of the display device. 
This enables a control device (the FAV node) to present a general control user interface for all 
devices in the home network, irrespective of the differences in type and vendor. 



As described above, Legacy devices are devices that were built before the HAVI ... 
20 architecture or devices that select not to use HAVI. HAVI supports Legacy devices by providing 
Legacy DCMs to provide protocol conversions for Legacy devices. These Legacy DCMs can 
contain sufficient knowledge to allow them to support an existing 1 or 2 way control protocol and 
provide a specific control interface to the devices that conform to HAVI. A legacy DCM acts as 
a bridge between the Legacy and HAVI devices. This approach allows HAVI also to interact 
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with any future device control protocols such as protocols being used for home energy 
management or security. 

It should be appreciated that the communications hardware and protocols used by the 
HAVI architecture are non-specific. The HAVI architecture is readily suited to the incorporation 
and use of any one of several communications mediums, with the simple requirement that the 
medium provides a generic communication mechanism that supports the HAVI interfaces. The 
basic model assumed is one of a logical communications back plane (e.g., IEEE 1394). All AV 
devices are assumed to be connected to this back plane, and can locate and communicate.with all 
other AV devices, as shown in Figure 1B. In a physical setting, it is likely that this logical back 
plane will consist of more than one physical communication medium. It is further assumed that 
multiple protocols may be in use on different physical media. The Home AV architecture 
abstracts above all of this and presents a generic model of communicating nodes. It will provide a 
mechanism above the Transport layer (functionally like a socket) to ensure network 
transparency. This mechanism can be described as "reliable, ordered datagram service" which 
will provide all fragmentation and re-assembly. 

Accordingly, a goal of the present invention is to support each and every physical bus the 
same, such that an application need not care which physical transport it is using. However, with 
the familiarity of IEEE 1394 in the electronics industry, features of the present embodiment are 
illustrated and described in view of functioning with IEEE 1394. Other buses such as CEBus and 
USB may not require all the same features. 



Referring now to Figure 2, an exemplary peer to peer, two IAV node HAVI network 200 
accordance with one embodiment of the present invention is shown. HAVI network 200 includes 
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a first IAV 201 (e.g., a television) coupled to a second IAV 202 (e.g., a receiver). IAV 201 and 
IAV 202 behave in a peer-peer manner, arbitrating for necessary resources amongst one another. 
They lack the resources to support the addition of a BAV or LAV device, but can perform 
meaningful activities within their context. The IAV. is not required to provide any standard Ul 
5 capability. There is no provision in the AV Architecture for "forward compatibility" or discovery 
of new functions (e.g. IAV 201 only knows the functions that IAV 202 supports based on SDD 
provided upon connection of IAV2). However, in accordance with the present invention, the 
features of the SDD can be easily exploited to perform "ad-hoc" feature discovery. 

10 Figure 3 shows a single FAV cluster HAVI network 300 in accordance with one 

embodiment of the present invention. HAVI network 300 includes an FAV 301 (e.g., a set top 
box) respectively coupled to a first LAV 302 (e.g., a television) a second LAV 303 (e.g., a VCR) 
and a BAV 304 (e.g., a digital camera). In HAVI network 300, 

FAV 301 controls Legacy and Base AV devices (e.g., devices 302-304), providing cluster-wide 
15 services. 

Figure 4 shows an FAV cluster integrated with an IAV peer to peer HAVI network 400. 
In accordance with the present invention, the configuration of HAVI network 400 provides support 
for legacy devices 302 and 303 while enabling independent control to occur within the two IAV 
20 devices 401 and 402 when their resources are not in use by the FAV device 301 . The IAV 
devices 401 and 402 behave as peers to the FAV device 301. For efficiency, a resource conflict- 
policy can be implemented for both FAV to FAV or FAV to IAV resource"requests. The IAV will 
be controlled by the FAV by via a DCM running in FAV 301. 
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Figure 5 shows an exemplary HAVI network 500 having multiple FAVs. HAVI network 
500 includes an additional FAV 501 (e.g., a satellite receiver). This configuration behaves in a 
similar manner to HAVI network 400 described above. In this configuration, the FAV devices 301 
and 501 act as peers. 

5 

THE COMPUTER SYSTEM PLATFORM 

With reference now to Figure 6 ( a diagram of a set top box 301 in accordance with one 
embodiment of the present invention is shown. As described above, any consumer electronics 
device can be a FAV and thereby provide a computer system platform for HAVI software. For 

10 instance, the set-top-box 301 device of the exemplary HAVI network contains special 
components that provide an operation platform for software components of the HAVI 
architecture which are described below. Specifically, aspects of the present invention, described 
below, are discussed in terms of steps executed on a computer system (e.g., processes shown in 
Figures 13 through 17A). Although a variety of different computer systems can be used with the 

15 present invention, an exemplary general purpose computer system is shown in the set-top-box of 
Figure 6. 

Set-top-box 301 of Figure 6, in addition to having a video/audio receiver (decoder) unit 
606 and MPEG unit 607 also includes an address/data bus 600 for communicating information, 

20 one or more central processors 601 coupled with the bus for processing information and 

instructions, a volatile memory 602 (e.g., random access memory RAM) coupled with the bus 600 
for storing information and instructions for the central processor 601 andu non-volatile memory 
603 (e.g., read only memory ROM) coupled with the bus 600 for storing static information and 
instructions for the processor 601. Set-top-box 301 can also optionally include a data storage 

25 device 604 ("disk subsystem 0 ) such as a magnetic or optical disk and disk drive coupled with the 
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bus 600 for storing information and instructions. Also included in the set-top-box 301 is a bus 
interface unit 608 for interfacing with the local bus 30 (e.g., an IEEE 1394 serial bus). Set-top-box 
301 can operate under a variety of different operating systems (e.g., Windows operating system, 
DOS operating system, Macintosh O/S), but in the present embodiment the Aperios operating 
5 system is used. 

THF HAVI SOFTWARE MODEL 

In accordance with the present invention, the computational units of the HAVI 
architecture (e.g., DCMs) are modeled as objects. Each object is a self contained entity. 
10 accessible through a well defined interface and executing within a well defined software execution 
environment. The software execution environment (e.g., set top box 301 from Figure 6) provides 
a set of well defined services (locally or remotely) that are also modeled as objects and can be 
accessed, using the communications infrastructure, via their well defined interfaces. 

15 Each object is uniquely named. No distinction is made between objects used to build 

system services and those used for application services. All objects make themselves known via 
the registry. Objects in the system can query the registry to find a particular service or device 
and can use the result of that query to send messages to that service or device. The identifier 
assigned to an object is created when the object registers. This identity, if required, is 

20 guaranteed to be persistent during the lifetime of the object and will remain persistent even in the 
face of a complete reboot of the home network. 



25 



In accordance with the present invention, the objects communicate using a message 
passing model. An object that wishes to use the service of another object, does so by using a 
general purpose message passing mechanism that delivers the service request to the target 
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object. The target object is specified using the unique object identifier discussed above. While in 
the present embodiment the message passing mechanism functions with IEEE 1394 t it should be 
noted that there is no distinction between sending a message across a 1394 bus, or over a 
Control A1 link. In the same manner, there is no distinction between objects on the same node 
5 and one on a remote node. . The actual implementation of the message passing infrastructure will 
depend on the system and networking environment and will differ from node to node and between 
vectors; However^^^ must be common so that interoperability 

is assured. 

1 0 It should be appreciated that the general intent of the object model and messaging system 

is to provide a completely generic software model that is sufficiently flexible to allow multiple 
implementations with a variety of software systems and languages. Details of the binding 
between messages and the code that handles them are left to the system implementor. 

15 SOFTWARE ARCHITECTURE OVFRVIFW 

The HAVI software architecture defines the way that the software model is used to 
support the HAVI architecture. In particular it defines the way that devices are abstracted and 
managed within the AV architecture. It defines the ways that interoperability is assured, and it 
defines the ways that future devices and services can be integrated into the architecture. 

20 

Full AV nodes as software managers: In accordance with the present invention, Full AV 
nodes (FAVs) act as managers for Intermediate (lAVs) and Base (BAVs)-nodes and provide a 
platform for the services that support the HAVI architecture. To achieve this they provide an 
execution environment which allow objects to control and communicate with services and devices. 
25 To ensure that devices are accessible within the Home AV network, the FAV nodes support a 
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software abstraction of the services that a device offers to others. As described above, this 
abstraction is referred to as a device control module (DCM). The DCM is modeled as an object 
within the software architecture but is refereed to hereinafter simply as the DCM to distinguish 
it. The interface that the DCM exposes to the rest of the system provides the means to access 
5 and control that device. In the general case, a FAV will manage a set of DCMs, one for each 
IAV node and base node in the home network or portion of the IAV network that it manages. 
Thus, it should be appreciated that from an interoperability perspective,- the primary role of the 
FAV node is to manage DCMs of the present invention and act as an execution environment for 
DCMs. 

10 

Full AV node as controller and display device: In accordance with the present invention, 
in most cases, FAVs will have an associated display device which is used for display of AV 
content and of user interface (U I) material. However, the HAVI software architecture does not 
mandate this and FAV nodes may be "headless". In this case they will cooperate-operatewith 
15 other nodes to display content and Ul information (see below). However, FAV devices will be 
responsible for supporting the high level Ul APIs that provide the look and feel of the entire home 
network. The lower level graphic manipulation APIs wiil generally be located close to the graphics 
display device itself and are manipulated by the FAV high level APIs. 

20 Peer to peer architecture between full AV nodes: in a Home AV network in accordance 

with the present invention, there may be more than one FAV. In this case, each FAV cooperates 
with other FAVs to ensure that services are provides to the user. This allows FAV nodes to 
cooperate to share resources. For example, an FAV node that does not have direct access to a 
display device, may use a remote FAV node to display DCM user interfaces. Alternatively, a 
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FAV node may require the services of a data translation module that exists on a remote node to 
allow it to set up a data route between two AV devices. 

LEVEL 1 AND LEVEL 2 INTEROPERABILITY GENERALLY 
5 In accordance with the present invention, one of the major goals of the HAVI architecture 

of the present invention is to support interoperability between devices. This includes existing 
devices and future devices. To achieve that interoperability, the HAVI architecture of the 
present invention supports a general model that allows two levels of interoperability. These 
levels are referred to as Level 1 and Level 2. 

10 

Level 1 interoperability: Level 1 interoperability of the present invention addresses the 
general need to allow existing devices to communicate. To achieve this, level 1 interoperability of 
the present invention defines and uses a generic set of control messages (commands) that enable 
one device to talk to another device and a set of event messages that it should reasonably 
15 expect from the device. To support this approach a basic set of processes are required. These 
processes include device discovery, communication, and a generic message set. 

The device discovery process of the present invention provides for the fact that each 
device in the Home AV network needs a well defined method that allows it to advertise to others 

20 its characteristics. The approach we have adopted is to specify a data structure, required on all 
FAV and IAV devices, that contains information about the device and which can be accessed by 
all other devices. This data structure is referred to as a Self Describing Data structure (SDD). 
The SDD contains, as a minimum, enough information to allow another device to discover its 
basic capabilities and so infer the basic set of command messages that can be sent to that 

25 device and events it should reasonably expect to receive from that device. 
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The communication process of the present invention provides for the fact that once a 
device has determined the capabilities of another device, it then needs to be able to access those 
capabilities. To achieve that requires a general communication facility that allows one device to 
5 send a message containing a command request to another device. The general message service 
processes of the present invention were discussed above. 



Generic message set refers to the process required to support level 1 interoperability. 
This includes a well-defined set of messages that must be supported by all devices of a particular 
10 class. This ensures that a device can work with other devices, irrespective of the manufacturer, 
because all devices agree to a common set of generic commands. As discussed above, within the 
HAVI software architecture of the present invention, these commands are presented as a DCM 
to the rest of the system. 

15 These three basic processes of the present invention support at least a minimal level of 

interoperability. Since, in most cases, any device can query the capabilities of another via the 
SDD, any device can determine the command set supported by another device. And since each 
- device has access to a generic messaging system, then any device can interact with any other 
device. 

20 

However, it should be appreciated that level 1 compatibility in accordance with the 
present invention only ensures that devices can inter-operate at a minimal or degraded level of 
functionality. The generic message set for each device class is a minimal and common set of 
commands. The SDD facility offers a means to provide some degree of customization of a 
25 device by providing information about its Ul and some aspects of its interaction model. Other 
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IAV devices can use this information to present an interface to the device. Alternatively, any 
FAV device can use this information to customize the generic DCM it has created for the device. 
However, it should be noted that a more extensible mechanism is also needed to allow a device to 
communicate to other devices any additional functionality it posses. Level 2 interoperability of 
the present invention provides this mechanism. Level 1 and Level 2 interoperability are discussed 
in greater detail below. 



LEVEL 1 AND LEVEL 2 DCMs 

As described above, the DCM of the present invention functions by providing access, 
control and interaction with a device. DCMs are typically instantiated (e.g., executed) on the 
resources of FAVs in the Home AV architecture. The DCM of the present invention provides an 
interlace to a device and manages a Ul that the device wishes to present to users. 

In accordance with the present invention, with the level 1 interoperability, the DCMs 
created for devices are generic. They support a minimal command set that allows generic 
control of the device. To support device specific features requires that the DCM provide access 
to such device specific features and is capable of presenting device specific features to users via 
the UL 

To achieve this, Level two interoperability is used. In accordance with the present 
invention, the Home AV architecture allows a device to provide an "override" DCM for the 
generic DCM that would normally be created for that device. The override DCM (e.g., level 2 
DCM) is capable of replacing the default DCM (e.g., level 1 DCM) on the FAV. It should be 
appreciated that the level 2 DCM could be retrieved from a variety of sources. One such source 
is the SDD of the device itself. In this case, the level DCM is fetched, received, or otherwise 
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acquired from the SDD of the device and instantiated in an FAV node when the device is installed 
into the system. Because the Home AV architecture is vendor neutral, it is necessary that the 
level 2 DCM work on a variety of FAV nodes, each with potentially different hardware 
architectures. To achieve this, the format of both the level 1 and level 2 DCMs of the present 
invention are architecture neutral such that a wide variety of software execution environments 
of the FAV nodes are able to instantiate and run the level 1 and level 2 DCMs. 

It should be appreciated that, in accordance with the present invention, once created and 
running within a FAV node, the DCMs of the present invention communicate with the IAV and 
BAV nodes in the same manner as described above using the basic messaging mechanism. 

As described above, there are many permutations of FAV, IAV and BAV nodes possible 
within a given HAVI network. These permutations generally fall into two types: HAVI network 
configurations that support an FAV device, and those that do not. This distinction essentially 
defines whether a HAVI network will be using a peer to peer configuration (e.g., as shown in 
Figure 2, where no FAV is present) or will be imposing some form of control hierarchy (e.g., the 
FAV cluster as shown in Figure 3). 

In accordance with one embodiment of the present invention, in the cases where no FAV 
is present, only level 1 interoperability is available and the devices are forced to use SDD 
information to discover other IAV capabilities, present those capabilities, and control the device. 
In the cases where FAVs are present, DCMs are instantiated and uses. If These are level 1 (e.g., 
generic) DCMs, the devices are operating at level 1 interoperable If there is at least one level 2 
DCM present, then some of the devices are operating at level 2 interoperability. 
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In accordance with the present invention, it should be noted that a mixed mode of 
operation is possible in which clusters of devices are inter-operating under control of an FAV 
node, while other devices are inter-operating in a peer to peer fashion. In this manner, the 
5 flexibility of the present invention allows vendors the freedom to design and build devices ate all 
points on the cost/capability spectrum with the certainty that these devices will inter-operate 
seamlessly with other devices in the HAVI network. 

Referring now to Figure 7, a logical block diagram 700 of one embodiment of the HAVI 
10 architecture is shown. Figure 7 shows an overall HAVI architecture in accordance with the 
present invention. The components shown in diagram 700 are as follows: 

Device manager 761 : Device manager 761 is responsible for creating and managing the 
DCMs that represent devices managed by an FAV device. 
15 Device Modules 720: These are the DCMs for individual devices. As described above, 

each DCM functions as a control point for a device and provides a Ul component and a control 
component The DCMs (e.g., device modules 720) provide an API to allow other applications to 
access and manipulate the devices. 

Service Modules 730: These modules can be viewed as software devices They are 
20 DCMs for any software component (as opposed to a hardware device) that provides a general 
service to other devices or components in the home network. 

Comms Media Manager 740: This component is responsible for managing the underlying 
physical communications process. It provides an API that allows code modules to interact with 
the features of the communications media (e.g., IEEE 1394). 
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Registry 706: This is a service database. All DCMs for physical devices and software 
services will register themselves in the registry 706 and all modules (e.g., device modules 720) can 
query the registry to get a handle for another device or module. 

Communications manager 750: This component is a low level abstraction of the 

5 communications media. 

Messaging 702: This component provides a basic message passing facility to allow both 
devices (hardware) and device modules 720 and service modules 730 to communicate with each 
other. 

Event Manage 703: This module provides a generic event service. This is a one-to-many 
10 communication service allowing notification in the HAVI network. 

Initialization manager 701 : This component is used as part of the device bootstrap 
process. 

Data routing 762: The data routing component 702 is responsible for helping services set 
up routes between devices and devices modules. It takes into consideration the 'cost* of 
15 transferring data via a particular route, the requirements on data format translation etc. This 
component is not needed for the basic architecture. 

AV Actions/Macros 763: this component is a manager for higher level AV actions which 
are groups of individual low level commands, i.e. it provides a macro service. This component is 
not needed for the basic architecture. 
20 High level Ul library 704: This component provides a set of high level Ul components that 

are used by device modules 720 to build Uls for their corresponding devices. This component is . 
not needed for the basic architecture. 

Application (and User) interface 705: This component provides the linkage between a 
common consumer electronics platform (CCEP) APIs of the HAVI compliant devices and 
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applications which are local or possibly remote. This component is not needed (or the basic 
architecture. 

It should be appreciated that the above components as diagrammed in Figure 7 are 
abstractions of functionality. They are designed to make clear what functionality is included in 
the architecture for HAVI compliant devices. In order to avoid unnecessarily obscuring the 
present invention, the relationship between components 701-763 arid the message flows between 
them are not shown. 

PCM CONFIGURATION AND FUNCTION 
Overview 

In one embodiment of the present invention, in HAVI network configurations where a FAV 
node is available, a DCM exists for each physical device in the HAVI network known about by 
that FAV node. The DCM provides an interface to the device and presents it as an object in the 
architecture. Other DCMs, system services or application services can query the local registry 
to find out the devices available and to get an identifier to allow them to interact with the devices 
via its DCM. 

Device control modules are also responsible for interacting with the software 
architecture to present the device user interface (Ul) to the user. Input from users is then passed 
to the DCM which uses the input to control the actual device. 

As discussed above, DCMs support the level 1 and the level 2 interoperability. A level 1 
DCM is a generic DCM, usually supplied with the FAV node, and capable of managing a basic, 
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pre-defined set of features of a device class using a pre-defined message set. During 
initialization, the DCM will work with the Device manager (below) to discover the actual 
characteristics of the device to be managed, and will configure itself to control that device. Thus 
a generic VCR controller could be instantiated to control a standard VCR using either 1394 
5 AV/C messages, or via Control A1. 

In the case of level 2 interoperability, the DCM instantiated for that device will be an 
override DCM that has been loaded from an external source, e.g. the device itself. These 
override DCMs are written in the common language format for DCMs. The functioning of an 
10 override DCM doesn't differ from generic ones but the API offered is likely to be more 
comprehensive. 

Once instantiated, DCMs will provide not only control interfaces for the device, but also 
access to SDD data associated with a device. They will act as event managers for a device, 
15 receiving device specific events and posting those to the event system (see below). They will 
also act as Ul manager for the device, interacting with the Ul management system to provide a 
user interface via some display device. Lastly, the DCM will operate as a resource manager for 
devices, arbitrating requests made for device access and service. 

20 General DCM terminology 

In the terminology of the present invention as used in the following descriptions, each 
DCM presents a model of a device in the home network. The basic terminology used is as 
follows: 
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1) Device: This term refers the entire device. 

2) Subdevice: This term refers to one of possibly many components that make up a 
device. Some technologies do not have the ability to distinguish subdevices. 

3) Internal Connection: This term refers to the logical or physical connection between 
internal subdevices. 

4) External Connection: This term refers to the connection between a physical 
connector on the outside of a device and a destination device outside the device. The same as 
unit Serial Bus and external input and output plugs for AV/C. 

5) Protocol: This term refers to the control protocol spoken by the sub-device or device 
(e.g., AV/C, Control A1, etc.). It should be note that a device may contain subdevices which 
speak different protocols. 

6) Interface: This term refers to the physical bus connection interface (1394, USB, 

etc.). 

7) Device Class: This term is one way to describe the basic functionality of a given 
collection of devices. For example, the class of DVCR devices can record data to a tape 
medium. Likewise, there may be many devices that can take audio input, perform some kind of 
special effects, and output the modified audio stream. These would all come under the class of 
audio processor or something like that. The usefulness of this concept will become more apparent 
later in the document. 

8) Device Model: This term refers to the collection of subdevices and connections that 
make up either a standard or custom device definition. Individual subdevices that are accessible" 
within physically separate devices can be combined to form logical or virtual devices using the 
device model. 
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9) Standard Device: This term refers to standard model definitions (e.g. a DVCR device is 
composed of at least a tuner subdevice and a VCR (transport) subdevice, with plugs between 
them). 

10) Special Device: This term refers to a vendor-specified device model, composed of 
5 either standard subdevices or a combination of standard and vendor-specific subdevices. For 

example, a dual deck DVCR may have two VCR subunits, which are standard items, but in a 
non-standard configuration. 

11) Aggregate devices: This term refers to logical entities which can be combined from 
a variety of components. Physical devices and subdevices are individually accessible pieces of 

10 hardware. When devices have accessible subdevices, this model is extended to support 

aggregate devices. Examples of aggregate devices include subdevices from separate physical 
devices or within a single device, and software modules such as software codecs which provide 
services or capabilities similar to devices and subdevices. These modules can all reside in the 
same node on the AV network, or can be distributed among many nodes.. 

15 

Device classification 

Classifying devices based on the kind of actions they perform, or the kind of medium they 
deal with, is a way of allowing us to create a generalized control API that will work for devices 
that are created in the future. The intent is to allow a high percentage of basic functionality to 
20 always be accessible regardless of the type of device or the manufacturer of the device. 

Any manufacturer-specific or device-specific functionality that is controllable as well but 
falls outside of the generalized control API will only be accessible via the SDD information and 
other techniques for extending a DCM. 
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ln the most general terms, the classification of devices or subdevices can be described by 
their main functionality. The AV/C control protocol of the 1394 standard uses a convenient 
method of classifying devices which we have adopted below. Following is the first set of factors 
5 used for classifying a device or subdevice: 

1) Whether a particular device has a transport mechanism. 

2) Whether the usefulness of this subdevice defined mostly by the fact that a signal ends 
up here (regardless of the fact that it may be propagated without changes). 

10 3) Whether a particular subdevice a signal source (e.g., does it have a signal output). 

4) Whether a particular device accepts input, performs some sort of processing, and 
then outputs modified data. 

5) Whether there is no signal input or output of any kind (e.g., is the device a utility of 
some kind, such as a mechanism for positioning a satellite antenna). 

15 

In accordance with the present invention, at a second level of classification, we can 
study devices that contain a transport mechanism. In this case, a general question would be 
"does this device deal with removable media?". If it does, then a basic set of controls is applied, 
such as Play() f Stop() and even SearchQ. Devices with media can be queried for their ability to 
20 record, to determine the organization of information on the medium (is it track-based? continuous 
such as a tape? how is it measured - SMPTE time codes, time offset from a certain position, 
etc.). 

In the present embodiment, a signal processing service can be described by the kind of 
25 signal(s) it can accept, and the kind it can produce as a result. This requires the establishment 
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of common definitions for describing signal types and methods for accessing the services, so that 
any client can know how to describe what kind of service it is looking for, and how to access that 
service. 

5 Any device which accepts one kind of data and has the ability to transmit that data on a 

different type of connection (for example, it takes digital video as input and has standard analog 
video RCA jacks which can send that data back out) can act as a data converter class. The 
DCM for these devices will register itself as a data converter in the system registry, so that 
clients can find them and use them as necessary. 

10 

Device access and control 

In accordance with the present invention, once a basic device classification has been 
made, then the generic DCM instantiated for that device will provide an API that causes control 
messages to be sent to that device. The base set of control messages that can be sent or 
15 received (in the case of events) to a particular class of device are standardized and detailed in 
the appendix (not available in this version of the document). In the present embodiment, these. , 
messages represent a basic API presented by the DCM. 

Device management 

20 In accordance with the present invention, the DCM API also provides a set of higher level 

services that allow more sophisticated management of the device. Examples of this include 
device reservation and event management. In the case of device reservation it is likely that a 
request for a device may be refused due to existing requests on the device, alternatively, the 
device request may be for a future reservation for a time based macro. In these cases the DCM 
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provide an interface to allow an application or service to queue requests with the DCM, i.e. 
reserve a device, or to receive notification when a device becomes available. 

Connection management 
5 The DCMs of the present invention also provide a high level API to allow other objects to 

query the state of connections between devices and to manipulate those connections. This API is 
primarily used by the Route manager but is available to any object in the system. Connection 
management allows connections to be established, both internally between subdevice units, and 
externally between devices. Connection status can be queried and connection capabilities [signal 
10 formats) can also be queried. 
.SDD management 

The DCMs of the present invention also provides a generalized interface to SDD 
management. This allows the SDD data in the device to queried and used. The API is divided 
15 into two parts, part 1 provides APIs for getting well know information from the SDD data 

including the Device Image, its name and the URL (if available) of a location for an override DCM 
or other icons to be used in representing the device's Ul. Part 2 of the SDD API is designed to 
provide more detailed access to functional aspects of the device. 

20 Device representation and user interface (Ul) 

In accordance with the present invention, the DCM is also responsible for the Ul aspects 
of the device. In the case of level 1 interoperability, a generic Ul is used to interface with users. 
This may be augmented by basic SDD data that allows such aspects as Ul icons to be specified 
and accessed by the generic DCM. In order to avoid unnecessarily obscuring the present 

25 invention, the details of how the DCM interacts with the Ul management system to present a 
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device specific Ul is not discussed in detail. In the present embodiment, however, the basic model 
is that internal management code within the DCM works with the Ul management system to 
present a Ul for the device. User input is then forwarded by the Ul management system, to the 
DCM which then converts it into device specific commands. These commands are sent, using the 
5 basic messaging system, to the device. If replies are received then these are passed via the 
DCM up to the Ul. In addition, any status changes of the device, e.g. on/off are also passed, via 
the event-system-to the DCM which uses them to update the Ul. 

Service Modules 

10 Service modules (e.g., service modules 730) are conceptually similar to device control 

modules. They provide an interface to a service which is usually provided by software only. In 
the present embodiment, service modules are of two types, system services and application 
services. A system service is a well know service that is provided as part of the HAVI 
software architecture. Examples of these types of services are data format translators, 
15 protocol converters or graphics services. These services have well known APIs which are 
defined as part of the HAVI architecture. Application services are objects that have been 
created for and by other service objects. These objects provide a well defined API, however that 
API is not public. In the present embodiment, any application or other object that wishes to use 
an application object needs to know its API and calling semantics. Although not required, 
20 generally, system services will exist for the lifetime of the system. Application services will 
exist for the lifetime of an application and may be quite short lived. 



25 



System services 

In accordance with the present invention, many of the services provided by the AV 
architecture are provided as service modules, who register their services in the system registry 
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and can be accessed using messaging. Examples of such sen/ices are the UI service modules 
that provide a mechanism to allow devices to present a UI to the user, data format services that 
convert AV data between different formats. 

THE PCM MANAGER 

Overview 

In accordance with the present invention, the DCM Manager is responsible for all aspects 
of handling the collection of DCMs resident on a FAV node. This includes the tasks of 
discovering, instantiating and disposing of all possible device control module candidates that are 
available to a given system. Device resource management is generally carried out by individual 
DCMs, however, where multiple devices or sen/ices are interacting and where some of the DCMs 
are located on different FAV nodes, higher level management will be needed. Therefore, the 
DCM Manager communicates with other DCM Managers on remote nodes to arbitrate for 
network-wide device and subdevice resource allocation and management. Its responsibilities are 
discussed below. 

Discovery and enumeration of physical devices 

In accordance with the present invention, the DCM Manager works with the underlying 
OS services to obtain a raw list of available devices. Note that depending on the underlying bus 
technology, these DCMs may be dynamic. In the present embodiment, for example, as physical - 
devices come and go on a 1394 bus the DCMs will come and go with them. "In the same manner, 
the service and aggregate device DCMs are also dynamic, being created and destroyed in 
response to events in the FAV node. 
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This task requires interaction both with elements of the AV architecture and also with 
elements of the FAV host OS, node hardware and communications hardware. Due to this, the 
exact process required for device discovery will depend on the system environment. However, 
5 the general approach, of querying a device and any SDD data it contains to discover its 
characteristics, as discussed in the DCM section, is common. In the present embodiment, this 
-requifeslhXDCM managerTo follow aTet of rules" in a given sequence each time the system is 
initialized, or any time the system may change (such as when the bus is reset). 

10 Creation of Generic DCMs 

In accordance with the present invention, for each node, the DCM Manager does enough 
work to determine that it should create a DCM. This work is carried out for all media-related 
devices which will be managed by the FAV node. In the present embodiment, Devices under a 
different management technology, e.g. USB based devices, may be presented within the 
15 architecture as DCMs on nodes that support USB communication, or as special DCMs that act 
as proxies for a remote management system. It should be noted, however, that some USB- 
based devices such as hard disks may in fact be made to appear simply as random-access media 
recording or playback devices; in these cases, they are treated like any other "rear media 
device. In the present embodiment, for each media-related entity, the DCM Manager will create a 
20 generic or level 1 DCM. Each DCM will later have the responsibility to make itself more device- 
specific if possible. This is described below. 

Integ ration of level 2 DCMs 

In cases where an over-ride (e.g., level 2) DCM is available and accessible, 1he DCM 
25 manager is responsible for attempting to fetch that DCM and installing it into the FAV node. In 
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the present embodiment,, the details of how the over-ride DCM and the generic DCM interact is 
dependent on the DCM developer. For example, in some cases it will completely replace the 
default DCM, in others it will work with the default DCM to augment its capabilities. 

5 In accordance with the present invention, manufacturer-supplied level 2 DCMs may come 

from a variety of sources. Devices may carry them within their ROM or some other storage 
mechanism such as the header of a disc or tape. They may be downloaded from a web or ftp 
site if such capabilities are accessible to the FAV node, or they could be supplied in the typical 
computer industry manner, via an installation from a disk or other storage medium. Allowing this 

10 manufacturer-supplied over-ride DCM capability requires a model for creating and installing 

DCMs. In the present embodiment, when installed, the level two DCM will provide the same base 
interface to the client as a level 1 DCM, while either providing additional interfaces or just 
underlying functionality modifications. 



15 DCM Disposal 

In accordance with the present invention, the DCM Manager will be responsible for 
disposing of DCMs at the appropriate times, and notifying clients that DCMs have been removed. 
In the present embodiment, the rules for when DCM disposal occur, and the distribution of 
responsibility for clean up, between the DCM and the DCM Manager, are tailorable to for the 

20 specific requirements of a particular HAVI network. 

Coordinate Amongst Multiple DCMs 

Some complex services among multiple DCMs, for example, command queuing of complex 
operations, etc., require the DCM Manager to coordinate with multiple DCMs to carry out these 
25 operations. This will be influenced by the "command model* that is provided for clients. For 
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example, if we define an upper level API that allows clients to specify actions that are based on 
HH:MM:SS:FF time codes, then we need to translate between this time model and whatever the 
hardware or underlying support modules deal wfth. It shou.d be noted that complex time-based 
operations that are affected by mechanical delays, etc., need to be accounted for. This type of 
coordination requires some notion of real time behavior in the network and is dependent on the 
physical and software infrastructure providing some level of guarantee. 

Referring now to Figure 8, a layered logic diagram 800 of one HAVI architecture in 
accordance wfth the present invention is shown. The components shown in diagram 800 are 
similar to those shown in diagram 700, however, diagram 800 is organized such-that high level 
processes are on top (e.g., applications 801) with respect to lower level processes on the bottom 
(e.g., 1394 module 830). Diagram 800 also depicts other services 810. transportation adaptation- 
modules 815, and other modules 840. 

5 As described above, the overall HAVI architecture can be shown as communications 

components and service components. Applications 801, at the highest level in the architecture 
use the services and the communication components (e.g., DCMs 720. service modules 730, etc.). 
,ntum.anumber of the se*ice components (e.g.. service modules 730, DCMs 720, etc.) will use 
the underlying communications components (e.g.. messaging 702. transportation adaptation 
20 modules 815, etc.). For example, in the case of one of applications 801 requesting, via the 

registry 706. the handle for a DVTR (digital video tape recorder) device, and then sending a play 
command to the device. As described above, components in the HAVI archrtecture communicate 
using the underlying messaging system, i.e. the modules use message passing. 
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Figure 9 shows a diagram 900 of local and remote messaging in the HAVI architecture of 
one embodiment The messaging component 702 is shown handling both local messaging and 
remote messaging. Hence the messaging component 702 is depicted at the base of diagram 900. 
Local messages are shown as arrows 902a, 903a, 904a ( to various applications 901-904. A 
5 remote message is shown as arrow 901b. For the sake of clarity, in diagram 900 and in the 
following discussions, local communication via the messaging system is not depicted, rather, local 
messaging (e.g., arrows 901a-904a) are shown as if based on direct function calls between 
components. 

10 Figure 10 shows a diagram 1000 of a message being sent via 1394 in the HAVI 

architecture of one embodiment. In diagram 1000, message 1 (e.g., arrow 820a) is a request from 
one of applications 801 to the registry 706 (via the query API) for the handle of a DVTR device. 
The registry 706 returns a handle for the DVTR DCM in message 2 (e.g., arrow 820b). This 
handle is the message address used for the messaging system. 

15 

In accordance with the present invention the application then uses the handle to invoke 
the DCM for the DVTR with message 3 (e.g., 820c). The DCM converts the application 
invocation of the play call to an internal command which is sent to the messaging component, 
message 4 (e.g., arrow 820d). This internal command is part of the well defined command set at 

20 level 1 , i.e. it is a HAVI command. The messaging component 702 then internally uses the handle 
information to determine which bus this device resides on. When it discovers that it is on the IEEE 
1394 bus, it uses the IEEE 1394 transport adaptation module (TAM) 830 to convert the message 
to a 1394 packet, message 5 (e.g., arrow 820e), which is placed in the data portion of a FCP 
packet. The TAM then calls the 1394 device driver, message 6 (e.g., arrow 820f) to send the 

25 message over 1394. 



WO 99/35753 



•46- 



PCTAJS98/27758 



At the receiving side (not shown), the message will be delivered to the 1394 device 
driver, and then passed up through a 1394 TAM to the Messaging component. The messaging 
component will receive a HAVI message packet which it will then deliver to the receiving code 
5 directly via a message queue or callback function. In the present embodiment, if the receiving 
device is an IAV device, it will only have the communications component of the CCEP 
architecture and the registry. Any other functionality it has will be device specific. 

It should be noted that the previous example in Figure 10 illustrates a distinction in the 
10 HAVI architecture between the messaging system and the command set used to control devices. . 
In accordance with the present invention, the messaging system is a generic messaging 
mechanism that provides a message packet with a data section whose contents are completely 
opaque to the messaging system. For example, the messaging system can carry private 
application to application commands, AVC-CTS commands, CAL commands or any other 

15 command. The DCM is the entity responsible for communicating with remote devices, it uses the 
messaging system to carry commands specific to that device. For a level 1 HAVI compliant 
device, the command set carried by the messaging system is defined as part of the CCEP 
architecture. Messages carried by the messaging system between DCMs and devices they 
control contain these well defined commands. For level 2 devices the extended command set is. 

20 undefined, these may be pure AV/C-CTS, CAL or any other commands. 

Referring now to Figure 11, a diagram 1100 of an application invoking another application 
in one embodiment of the HAVI architecture is shown. Diagram 100 shows an application 801a 
running on a device 1 101 passing a message 1 105 to an application 801b running on a separate 
25 device 1 102 via messaging systems 702a and 702b. As described above, any application running 
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within the HAVI network can access any other application if it has a message handle for that 
application. To acquire a message handle, the same process is used as for a remote IAV device 
(e.g., described in Figure 10 above). Once a message handle is available, the source application 
801a can send a message 1 105 to the target application 801 b. As described above, the format of 
5 these messages is entirely dependent on the application and is of no concern to the CCEP 
architecture. It simply provides a communication mechanism to send a receive messages 
between the applications. 

It should be appreciated that in the above example, it is assumed that the applications 
10 801a and 801b reside on different AV devices 1 101 and 1 102. However, as discussed previously, 
it is quite possible that these applications 801a and 801b will reside on the same AV device and so 
the messaging system will perform a purely local communication call rather than a call that uses 
1394 to transport the message. 

15 Invoking a software service 

A software service is a special case of the generic application case above. In 

accordance with the present invention, a software service is simply an application that is part of 

the system infrastructure. In this case, when a module wishes to invoke a system service, e.g. 

the Ul component, it uses the messaging component to do this. If the Ul component is local then 
20 the call is contained entirely within one AV device. However, if the Ul component is remote, then 

the call will be routed over the 1394 network to the remote AV device, where the message 

system will dispatch the call to the Ul system service. 



Adding a new device to a HAVI network 
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ln adding new devices to a HAVI network, there are 3 general situations: handling a 
legacy device using a legacy protocol carried over a non 1394 network; handling a base device 
using a non HAVI protocol over a 1394 network; and handling a new IAV device that is HAVI 
compliant. 

5 

In the case ot adding a legacy device, in the present embodiment, a legacy device can 
only be directly controlled by an FAV node. As described above, for each legacy device, a 
legacy DCM must be created. Consider an FAV that has a 1394 port and an Ethernet port 
The CMM module will have been configured to manage both 1394 and Ethernet When the legacy 

10 device becomes know to the FAV, it will first become known at the CMM module. Note that the 
mechanism used to achieve this is not within the scope of the CCEP architecture. It is 
communications media specific. Once the CMM recognizes a new device, it will go through 
whatever media specific mechanism it uses to determine the type of the device. Again this is not 
part of the CCEP architecture. Eventually it will ask the DM to instantiate a legacy DCM for 

15 this device. It is assumed that the FAV node has been pre-configured with this DCM. 

In the present embodiment, once the DCM is created, it registers itself in the same way 
as any standard DCM. However, one crucial difference between this DCM and other DCMs is 
that the communication model and the command set used to control the legacy device is 
20 completely unknown to the CCEP architecture. For example, it is possible that the device is an 
IP device that implements a printer service. In this case the DCM will provide a set of commands 
such as Print. Status etc. When an application calls the DCM API with a print request, the print 
command will be sent out by the DCM. via an IP stack, to the printer device. The actual details 
of how this happens are implementation specific. 
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ln accordance with the present invention, one possibility is that the legacy DCM has a full 
implementation of the IP stack within the DCM and knows how to bind to the Ethernet device 
driver. Another possibility is that the FAV device provides an IP stack and a higher level API 
5 such as sockets. These are FAV implementation details and not part of the CCEP architecture. 
However, it should be noted that the legacy DCM is acting as a "proxy" DCM. Once it has been 
registered in the registry, it is visible to all other modules in the home network. They can all 
invoke its API and it performs-the necessary conversion to the private command language of the 
Ethernet IP printer. 

10 

In the case of adding a base AV device, in the present embodiment, when the CMM is 
informed about the new device, its recognizes that this is not a CCEP node, but it also discovers 
that a DCM is available for this device. In this case, the CMM is responsible for implementing a 
mechanism that allows it to upload the DCM and to ask the DM to create this DCM. However, 

15 once the DCM is instantiated then it uses a purely private communication mechanism to access 
and control the device. As described above, in the present embodiment, a base AV device is one 
that uses 1394 and implements the over-ride DCM but does not implement any of the CCEP 
architecture and will not implement level 1 HAVI commands. An example of this device could be 
one that contains an over-ride DCM but does not support the CCEP communications 

20 infrastructure. 



In the case of adding an IAV device, it should be appreciated that in the previous 
examples, the application queried the registry to get a message handle for the device it wished to 
communicate with. Note that for a FAV device, the handle returned is always used to access 
25 the DCM. It is not possible to send messages directly to the device. To understand how a device 
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which is added to the network becomes available via the registry then the following example is 
used 

For example, assume a new device (e.g., a camcorder) is plugged into the HAVI network 
5 (e.g., 1394 based). This causes a bus reset. The bus reset is handled by the Communications 
media manager (CMM) on the IRD. The CMM is responsible for querying the SDD data of the 
-eamcorder device-to^iswverits capabilitiesr Assuming is a level 1 device, i.e. it does 

not have an uploadable DCM,.then the CMM informs that Device Manager, that a new device 
has been installed. The Device Manager creates a new DCM for this type of device and 
10 registers the DCM with the registry. The DCM, when it initializes is free to query the device 
directly to find out more information about itself and to specialize itself if needed, e.g. it can 
access Ul information if it exists in the device. Once the DCM is registered in the registry, then 
any other module can query the registry to get a handle for the device and communicate with the 
DCM to access and control the device and present the Ul to the user. 

For example, Figure 12A and 12 B show an exemplary Ul display (e.g., on a television 
screen) for such a device(e.g., the camcorder). Figure 12A shows a text menu display, where the 
user is presented with the various controls that can be modified using the control names and 
control values. For buttons, the user can select them (which equates to pushing a button). Figure 
20 12B shows a "next level" Ul display for the camcorder. Here, the user selected the main panel 
from the menu in Figure 12A, and the display presents controls based on their grouping 
information. In the present embodiment, group names are used on a tabbed interface to allow the 
user to navigate between groups within the selected panel. 
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Referring now to Figure 13, a flow chart of a process 1300 in accordance with one 
embodiment of the present invention is shown. Process 1300 shows the steps of a method for 
providing seamless interoperability and integration of a plurality of devices in a HAVI network by 
using the SDD information stored in each device. Process 1300 begins in step 1301, where a new 
device is coupled to a HAVI network. In step 1302, the device is queried to obtain a description 
(e.g., SDD) of level 1 functions supported by the device. In step, 1303, a level 1 DCM, which 
^l^entslhe leve] ^functions, is generated for the device based upon the SDD. In step 1304, 
the device manager determines whether the new device contains software for a level 2 DCM. 

Referring still to Figure 13, in step 1305, if the new device contains software for 
implementing level 2 functions, the software is retrieved from the device and in step 1306, a level 
2 DCM which implements the level 2 functions is generated using the software. In steps 1307 and 
1308, the device is continually accessed via the jevel 2 DCM. In steps 1309 and 1310, if the new 
device does not include software for a level 2 DCM, the new device is continually accessed via 
the level 1 DCM. In this manner, the combination of the level 1 DCM and the level 2 DCM allow 
the present invention to provide seamless interoperability and integration of the new device with 
the plurality of devices in the network. 

Figure 14 shows a flow chart of a process 1400 in accordance with one embodiment d 
the present invention. Process 1400 shows the steps of a method for providing a basic command 
functionality and an expanded command functionality between a plurality of devices in a HAVI * 
network. In step 1401, a device is coupled to a HAVI network which includes a FAV device. In 
step 1402, a generic level 1 DCM for the device is generated by the FAV device. As described 
above, the generic level 1 DCM is a basic abstraction of the capabilities of the device. The 
generic level 1 DCM enables the device to respond to a basic set of commands from the FAV 
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device. In steps 1403 and 1404, the FAV device uses the generic DCM to query the device to 
determine whether the device includes descriptive information (e.g., SDD). As described above, 
the descriptive information describes the capabilities of the device. In step 1405, if the device 
includes descriptive information, the FAV device generates a parameterized DCM for the device 
5 by modifying the generic DCM based upon the descriptive information. In steps 1406 and 1407, 
the device is continually controlled using the parameterized level 1 DCM. In steps 1408 and 1 409. 
.. rf the-device does not include descriptive information, the FAV device is continually controlled via 
the generic level 1 DCM. 

10 Referring now to Figure 1 5, a flow chart of a process 1 500 in accordance with one 

embodiment of the present invention is shown. Process 1500 shows the steps of a method for 
ensuring future upgradabil'rty and expandability of devices in HAVI network. In step 1501 , a 
default level 1DCM for a device coupled to the network is generated. As described above, the 
default level 1 DCM is configured to ensure at least a minimum degree of interoperability between 

15 the device and the other devices on the HAVI network. In step 1502, the device is accessed by 
other devices via the default level 1 DCM. As described above, the default DCM enables the 
first device to respond to a default set of commands from other devices on the HAVI network In 
step 1503, an updated level 1 DCM for the devices is either received or not received. In step 
1504, updated level 2 DCM for the device is either received or not received. As described above, 

20 the updates enable the device's capabilities and functionality to evolve (e.g., as new, more 
efficient software becomes available). 



25 



In steps 1509 and 1508, where an updated level 1 DCM is received, the updated level 1 
DCM is incorporated (e.g., this could involve merely modifying the current level 1 DCM) and the 
device is continually accessed- via this DCM until a later update is available. In step 1505. where 
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an updated level 2 DCM is received, the DCM manager on the host FAV device unlinks the 
current DCM, and in steps 1506 and 1507, the updated level 2 DCM is linked and the registry is 
updated to allow other devices within the HAVI network to access the updated level 2 DCM. 
This DCM is continually used for accessing the device until a later updated level 2 DCM is 
received. In step 1510, if neither an updated level 1 or an updated level 2 DCM is received, 
process 1500 continues operation with the current DCM (e.g., the last installed DCM). 

Figure 16 shows a flow chart of a process 1600 in accordance with one embodiment of 
the present invention. Process 1600 shows the steps of a method for providing seamless 
interoperability and integration of legacy devices with the HAVI compliant devices in a HAVI 
network. Process 1600 begins in step 1601, where a legacy device is coupled to the HAVI 
network. In step 1602, the legacy device is queried via the proprietary protocol to determine a set 
of basic capabilities of the legacy device. As described above, HAVI compliant devices use a 
common HAVI defined protocol. The legacy device typically communicates with external 
devices (if at all) using a proprietary protocol. In step 1603, process 1600 maps a set of basic 
commands from the common protocol to the set of basic capabilities of the legacy device. In step 
1604, a level 1 DCM for the legacy device is generated. As described above, the DCM is based 
upon the set of basic commands. In steps 1605 and 1606, the legacy device is continually 
accessed via the level 1 DCM such that the other HAVI devices are able to access the set of 
basic capabilities of the legacy device. 

Figure 17A shows a flow chart of a process 1700 in accordance with one embodiment of 
the present invention. Process 1700 shows the steps of a method of controlling devices within a 
home audio/video network using an application program from an external service provider. In 
step 1702, an application program is originated by a service provider (e.g., via cable television, 
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internet web site, etc.). In step 1703, the service provider communicates the application program 
from the service provider to an intelligent receiver/decoder device of the HAVI network over a 
logical channel. The application is subsequently instantiated within a computer readable memory 
unit of the intelligent receiver/decoder. 

5 

Referring still to Figure 17A, in step 1704, the application program queries the HAVI 
registry of the device (e.g., FAV device) to locate DCMs on the network and selects a respective 
DCM from the registry. In step 1705, the down loaded application determines a communications 
point information from the selected DCM. In step 1706, the application controls a respective 
10 device of the HAVI network by communicating with the respective device using the 

communication point information. In step 1707, if the application needs to control another device, 
steps 1704 through 1706 are repeated. If the application does not need to control another device, 
processes 1700 ends in step 1708. 

15 Figure 17B shows a diagram of a HAVI network 1750 with the service provider 1720 in 

accordance with process 1700 of Figure 17A. As described above, the application program is 
downloaded from the service provider 1720 to the HAVI network 1750. The application is 
instantiated on the processor 601 and memory 602 of the intelligent device (e.g., set top box 301). 
HAVI network 1750 also includes four HAVI devices, device 0 through device 3 (e.g., television, 

20 DVTR, etc.). 

nr.M MANAGEMENT API 

An example DCM management API in accordance with one embodiment of the present 
invention is shown below. In the present embodiment, the common DCM commands include areas 
25 such as connection management, information and status queries for the device and its plugs etc. 
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. Regardless of the type of device represented by the DCM, such message sets need to be 
supported. 



The following is a list of DCM management messages that, in the present embodiment, 
5 all DCM's need to support for the HAVI architecture: 



ChannelUsage(plug); // returns the 1394 isoch. channel used by the specified unit plug 
PlugUsage(channel); // returns the plug associated with the specified channel 

10 

GetDevicePlugCount(count); // returns the number of unit plugs on the device 
EstablishlnternalConnection(sourcePlug, destPlug); 
15 EstablishExternalConnection(sourcePlug, destPlug) 
StartDataFlow(plug); 
StopDataFlow(plug); 

20 

GetSourceConnection(in dest, out source); // given a destination plug, return the source to which 
it is connected (return the source plug of the transmitting device which shares the same isoch. 
channel) 

25 GetDestinationConnection(in source, out ); 
GetAIIConnection(); 
NotifyOnConnectionChange(); 

30 

GetDynamicConnectionCapability(); // report whether the target device supports dynamic 
connection changes or not (e.g., a non-1394 device) 

LockConnection(plug); 

35 

UnlockConnection(plug); 

GetConnectionStatus(plug); // status = busy, data transmission format, channel, bandwidth 
usage, etc. 

40 

BreaklntemalConnection(plug); 
BreakExternalConnection(plug); 
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GetinputSignalFormat(plug); 

setlnputSignalFormat(plug); 

5 NotifylnputSigna!Format(plug); // send a notification if the signal format is changed. 

GetSupportedlnputSignalFormats(plug); // repeat the above for output signals 

10 GetFunctionlnfoO; // return information about the functional modules within the device (e.g.. the 
AV/C subunits) 

GetDeviceTypeO; 

15 GetVendorName(); 

GetVendorLogo(); 

SetDevicePowerState(powerstate); 

20 

GetDevicePowerState(powerstate); 
GetSupportedPowerStates(list); 
25 NotiyPowerState(powerstate); 
ReserveDevice(); 
6etDeviceReservationStatus(); 
NotifyDeviceReservationStatus(); 

VendorDependentCommand(command parameters); // pass thru a vendor-specific command 
in the native protocol; 

Function Control Module (FCM) Messages; 

The function-specific messages correspond to the typical native commands such as 
PLAY, STOP, REWIND for the VCR functionality within a device. Because we need to address 
40 these messages to a well defined location within a device, we use the FCM-(Function Control 
Module) to represent the target of these messages. Like DCM's, there are some messages that 
have to deal with administration and management of FCM's. These messages are supported by 
all FCM's, independent of their particular domain. The messages are as follows: 



30 



35 
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GetFunctionType(); II VCR t tuner, disc, etc. 

GetFunctionlnfo(); // more detailed information about the function, such as the particular kind of 
5 disc player (DVD, CD, etc.) 

GetNumberOfPlugs(inputPlugs outputPlugs); // returns the number of source and destination 
plugs for the functional module 

10 GetFunctionStatus(); // current status of the functional module, including the status of source 
and destination plugs (input and 
output) 

GetPowerState(powerState); // functional modules may have individually controllable power 
15 states 

SetPowerState(powerState); 

GetSupportedPowerStates(list); 

20 

GetSupportedDataFormats(list); // returns the data formats supported by this functional module 

NativeCommand(params); // send the functional module a command in its native command 
protocol 

25 

The functional domain messages are based on the type of function (VCR, tuner, etc.). These are 
the typical PLAY, STOP, REWIND commands that one would expect. 

Level I interoperability includes both device-to-device and human-to-device interaction. 
30 The functional message sets such as PLAY, STOP and REWIND are used for device-to-device 
interaction. One example of this would be a video editing software package that wants to 
control any type of VCR; the program is designed with a very specific set of user interface 
controls which apply to all VCR's. When the user interacts with the application, the application in 
turn sends domain-specific commands such as PLAY and STOP to the target device. 

35 
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ln the HAVI architecture, the application will send these messages to the DCM, and the 
DCM will translate them into the native language of the target BAV device. If the target device 
happens to support the HAVI messaging architecture, then these commands don't need to be 
translated at all; they are simply sent as HAVI message to the HAVI target. 

Camcorder devices are essentially VCR like. Their additional functionality is part of the 
camcorder~effecTs, transttionsretc. They are as follows: 



stop() 
10 play() 
rewind() 
forward() 
recordQ 

15 // newMode of: VTR, CAMERA, STANDBY 

cameraControl(controlType) // controlTYPE defines control Type and subType structures eg 
zoom, zoomValue, or Effect, transitions etc. 

MiniDiscs are of the category random access storage, they support a base set of 
20 commands to control PLAY, FORWARD, etc and a set of command specific to random access 
media. The commands are as follows: 



stop() 
play() 
25 rewind() 
forward() 
record() 

volume(setValue) _ 
changeStatus(newMode) // newMode of: STANDBY 
30 seek(track) 
seekstartfj 
seekEndO 

mdcS // controlTYPE defines control Type and subType structures eg ii 

35 mode, random play. 
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Hard Disks are of the category random access storage, they support a base set of 
commands to control PLAY; FORWARD, etc and a set of command specific to random access 
media. The commands are as follows: 

5 

stop() 
playO 
rewind() 
forward() 

10 record(type) // type structure passes info to allow intelligent devices to optimise storage policy 

changestatus(newMode) // newMode of: STANDBY 

seek(track) 

seek(block) 

seekStartj) 
15 seekEndO 

HDDControl(controlType) // controlTYPE defines control Type and subType structures eg 
layout commands for block-structures 



With respect to user interfaces, it should be appreciated that a generic and simple Ul may 
20 be a textual based one, as shown in Figure 12A. A more sophisticated one, based on DCM 
specialization, may be as shown on figure 12B. Where graphical information, carried in SDD is 
used by the generic DCM to specialize itself. 



Hence, the present invention provides a home audio visual (AV) network which defines 
25 an open architecture for inter-operating CE (consumer electronic) devices in a home network, . 
The interoperability aspects of the present invention define an architectural model that allows 
CE devices from any manufacturer to inter-operate and function seamlessly within the user's 
home AV system. The system of the present invention includes a combination of a base set of 
generic device controls with an method to extend a base control protocol as new features and 
30 new CE devices are deployed within the home AV network. In so doing, the architecture of the 
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present invention is extensible, and can be readily modified and advanced as market requirements 
and technology change. 

The foregoing descriptions of specific embodiments of the present invention have been 
5 presented for purposes of illustration and description. They are not intended to be exhaustive or 
to limit the invention to the precise forms disclosed, and obviously many modifications and 
variations are possible in light of the above teaching. The embodiments were chosen and 
described in order to best explain the principles of the invention and its practical application, to 
thereby enable others skilled in the art to best utilize the invention and various embodiments with 
10 various modifications as are suited to the particular use contemplated. It is intended that the 
scope of the invention be defined by the Claims appended hereto and their equivalents. 
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CLAIMS 

What is claimed is: 

5 1 . A method of controlling devices within a home audio/video 

network, said method comprising the steps of: 

a) originating an application program at a service provider; 

b) communicating said application program from said service provider 
to an intelligent device of said home audio/video network; 

10 c) instantiating said application program within a computer readable 

memory unit of said intelligent device; 

d) said application program querying a name registry to obtain a 
communication point for a respective device control module, said name 
registry listing a plurality of device control modules supported within said 

1 5 home audio/video network; and 

e) said application program controlling a respective device of said 
home audio/video network by issuing commands to said respective device 
control module wherein said respective device is associated with said 
respective device control module. 

20 

2. The method as described in Claim 1 wherein said intelligent 
device is an intelligent receiver/decoder device and in step e) said 
application program controls a respective device of a plurality of devices of 
said home audio/video network, 

25 

3. The method as described in Claim 1 or 2 wherein said 
respective device is coupled to said intelligent device via a local bus. 

4. The method as described in Claim 1 or 2 wherein said 
30 intelligent device is a set-top-box. 
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5. 



a The method of Claim 1 wherein said home audio/video network 
has a plurality of consumer electronic devices coupled to a local bus, said 
method being one of controlling said devices within said home audio/v,deo 
network, wherein in steps d) and e) said respective device is a first dev,ce 
5 such that said application program queries a name registry to obta.n a 
communication point for said first device control module, said name reg IS try 
listing a plurality of device control modules supporting said devices w.th,n 
said home audio/video network; and said application program controls sa.d 
first device of said home audio/video network by issuing commands to said 
1 o first device control module wherein said first device is associated w.th sa.d 
first device control module. 

6 The method as described in Claim 5 further comprising the 
steps of said application program querying said name registry to obtain a 
15 communication point for a second device control module; and sa,d 

application program controlling a second device of said home aud,o/v,deo 
network by issuing commands to said second device control module 

wherein said second device is associated with said second device control 
module. 

7 The method as described in Claim 1 , 2 or 5 wherein said home 
audio/video network is a network of the home audio/visual initiative (HAVI) 
architecture. 

8. The method as described in Claim 3 or 7 wherein said local 
bus is of the IEEE 1394 standard. 

9. The method as described in Claim 5 wherein said intelligent 
device is an intelligent receiver/decoder (IRD) device. 

10. The method as described in Claim 5 wherein said intelligent 
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device is a digital television. 

11. The method as described in Claim 5 wherein said service 
provider is a cable television provider. 

5 

12. The method as described in Claim 5 wherein said service 
provider is a satellite broadcast provider. 

13. The home audio/video network comprising: 
10 a local bus architecture; 

a plurality of devices coupled to said local bus architecture wherein 
one of said plurality of devices is an intelligent device comprising a 
processor, a bus, and a computer readable memory unit; 

said intelligent device for receiving an application program that 
1 5 originated from a service provider and for instantiating said application 
program within said computer readable memory unit of said intelligent 
device; 

said application program for querying a name registry to obtain a 
communication point for a first device control module, said name registry 
20 listing a plurality of device control modules supporting said plurality of 
devices coupled to said local bus architecture; and 

said application program further for controlling a first device of said 
plurality of devices by issuing commands to said first device control module 
wherein said first device is associated with said first device control module. 

25 

14. The home audio/video network as described in Claim 12 
wherein: said application program is also for querying said name registry to 
obtain a communication point for a second device control module; and 
wherein said application program is also for controlling a second device of 

30 said plurality of devices by issuing commands to said second device control 
module and wherein said second device is associated with said second 
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device control module. 



15. The home audio/video network as described in Claim 13 
wherein said local bus architecture is of the IEEE 1394 standard. 

5 

16. The home audio/video network as described in Claim 13 
wherein said intelligent device is an intelligent receiver/decoder (IRD) 
device. 



10 17. The home audio/video network as described in Claim 13 

wherein said intelligent device is a digital television. 

18. The home audio/video network as described in Claim 13 
wherein said service provider is an internet web site and wherein said 

1 5 service provider and said intelligent device are coupled via the internet. 

19. The home audio/video network as described in Claim 1 3 
wherein said service provider is a cable television provider. 
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